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PREFACE 


This  datcdbase  specification  applies  primarily  to  USAFE  wings  and  only  broadly 
addresses  the  other  MAJCOMs.  Each  MAJCOM's  requirements  will  be  thoroughly 
specified  during  the  in-depth  analysis  that  will  precede  its  implementation. 

In  addition,  some  paragraphs  and  subtitles  have  been  added  to  or  deleted  from  the 
standards  specified  in  DoD  STD  7935.1,  24  April  1984,  as  a  result  of  their  perceived 
applicability  to  the  AFIRMS  database  located  at  the  wing  level. 
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SECTION  1.  GENERAL 


\ 

\ 

\ 

'V 

1.1  Purpose  of  the  Wing  Database  Specification.  The  objectives  of  this  Wing  Database 

Specification  for  the  Air  Force  Integrated  Readiness  Measurement  System  (AFIRMS),'^- 

^  -  -  -  - 

under  Contract  No.  F49642-83-C-0022,  are  to  describe  the  storage  allocation  and 

database  organization  and  to  provide  the  basic  design  data  necessary  for  the  construction 
of  the  system  files,  tables,  dictionaries,  and  directories. 

There  are  vast  differences  between  a  database  design  in  the  classical  sense  where  a 
DBMS  is  chosen  and  a  schema  (or  logical  design)  is  developed,  and  the  design  of  the 
AFIRMS  databases.  AFIRMS  can  accommodate  many  different  DBMSs  and  schemas. 
Complexities  arise  because  AFIRMS  resides  at  three  different  levels  of  the  command 
structure.  Standard  database  issues  such  as  security,  ad  hoc  query  capability,  and  data 
communications  become  very  complicated  when  the  ability  to  receive  and  transmit  data 
between  sites  is  considered  the  basis  of  the  system.  In  the  Analysis  Phase  of  the  initial 
block  of  each  segment,  the  database  designer  must  be  aware  of  these  problems  and  realize 
that  the  design  of  the  database  at  each  level  is  highly  dependent  upon  the  other  levels.  ^ 


1.2  Project  References.  Accurate  assessment  of  force  readiness  and  sustainability  has 
been  a  constant  concern  of  Air  Force  commanders  and  their  staffs.  This  concern  has  been 
supported  by  an  intensified  DoD-wide  interest  in  capability.  In  response  to  this  Air  Force 
concern,  the  Directorate  of  Operations  and  Readiness  initiated  the  AFIRMS  Program. 
AFIRMS  has  been  under  development  through  a  learning  prototype  and  is  being  designed  to 
provide  Air  Force  commanders  with  a  complete,  timely,  and  accurate  assessment  of  their 
operational  readiness  and  sustainability. 

The  Program  Management  Office  (PMO)  responsible  for  contract  management  of  the 
AFIRMS  Learning  Prototype  Phase  (LPP)  and  this  Database  Specification  is  the  Data 
Systems  Des  gn  Office  (DSDO/XO),  Gunter  Air  Force  Station  (AFS),  Alabama;  the  Office 
of  Primary  Responsibility  (OPRl,  is  the  United  States  Air  Force  Readiness  Assessment 
Group  (AF/XOOIM).  Three  operational  centers  have  been  in  use  as  LPP  testbed  sites: 

The  Pentagon,  Washington,  D.C.;  Headquarters  United  States  Air  Forces  Europe  (HQ 
USAFE),  Ramstein  Air  Base  (AB),  Germany;  and  the  52nd  Tactical  Fighter  Wing  (TFW), 
Spangdahlem  AB,  Germany. 


References  applicable  to  the  history  and  development  of  the  AFIRMS  Program  are 
listed  below,  along  with  references  concerning  documentation  and  programming  standards. 


Project  References 


a.  AFIRMS  Data  Requirements  Document,  Final,  SofTech,  Contract  No. 

F49642-83-C-0022,  31  May  1985.  (Unclassified) 

b.  AFIRMS  Economic  Analysis,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 

31  May  1985.  (Unclassified) 

c.  AFIRMS  Evolutionary  Implementation  Plan,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

d.  AFIRMS  Functional  Description,  Final,  SofTech,  Contract  No. 

F49642-83-C-0022,  31  May  1985.  (Unclassified) 

e.  AFIRMS  HQ  USAF  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

f.  AFIRMS  HQ  USAF  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

g.  AFIRMS  HQ  USAFE  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

m 

h.  AFIRMS  HQ  USAFE  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

i.  AFIRMS  Product  Descriptions,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 

31  May  1985.  (Unclassified) 

j.  AFIRMS  System  Specification,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 

31  May  1985.  (Unclassified) 

k.  AFIRMS  Transform  and  Model  Descriptions,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

l.  AFIRMS  Wing  Database  Specification,  Final,  SofTech,  Contract  No. 

F49642-83-C-0022,  31  May  1985.  (Unclassified) 

m.  AFIRMS  Wing  Subsystem  Specification,  Final,  SofTech,  Contract  No. 

F49642-83-C-0022,  31  May  1985.  (Unclassified) 

n.  System  Interface  Design  for  the  AFIRMS  LPP  and  the  Combat  Fuels 
Management  System  (CFMS),  SofTech,  Contract  No.  F49642-83-C-0022, 

28  February  1985.  (Unclassified) 

o.  AFR  700-5,  Information  Systems  Requirements  Board,  9  November  1984. 

(Unclassified) 
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System  Interface  Design  for  the  AFIRMS  LPP  and  the  Air  Force  Operations 
Resource  Management  System  (AFORMS),  SofTech,  Contract  No. 
F49642-83-C-0022,  2  November  1984.  (Unclassified) 

AFR  700-2,  Information  Systems  Planning,  26  October  1984.  (Unclassified) 

Automated  Data  Processing  (ADP)  Security  Policy,  Procedures,  and 
Responsibilities,  AFR  205-16,  1  August  1984.  (Unclassified) 

AFR  300-4,  Vol.  4,  Air  Force  Data  Dictionary,  1  May  1984.  (FOUO) 

Automated  Data  Systems  (ADS)  Documentation  Standards,  DoD-STD-7935.1, 

24  April  1984.  (Unclassified) 

Department  of  Defense  Dictionary  of  Military  and  Associated  Terms, 

3CS  Pub  1,  24  April  1984.  (Unclassified) 

AFR  700-1,  Managing  Air  Force  Information  Systems,  2  March  1984. 
(Unclassified) 

AFIRMS  LPP  ADP  Security  Plan,  SofTech,  Contract  No.  F49642-83-C-0022, 

13  February  1985.  (FOUO) 

AFR  300-4,  Vol.  3,  Air  Force  Data  Dictionary,  15  August  1983.  (FOUO) 

Sustainability  Assessment  Model  (formerly  CAC)  Functional  Description, 
Contract  No.  F33700-83-G-002005701,  8  April  1983.  (Unclassified) 

AFR  700-3,  Information  Systems  Requirements  Processing,  30  November  1984. 
(Unclassified) 

MIL-STD-480  Configuration  Control-Engineering  Changes,  Deviations,  and 
Waivers. 

MIL-STD-483  Configuraton  Management  Practices  for  Systems,  Equipment, 
Munitions,  and  Computer  Programs. 

USAF  Operational  Major  Command  Functional  Area  Requirement  (FAR), 
SofTech,  Contract  No.  F49642-82-C-0045,  15  December  1982.  (Unclassified) 

Unit  Combat  Readiness  Reporting  (C-Ratings)  (Unit  Status  and  Identity  Report 
(UNITREP),  RCS:HAF-XOO(AR)7112(DD)),  AFR  55-15,  22  November  1982. 
(Unclassified) 

USAFE  Annex  to  USAF  FAR,  SofTech,  Contract  No.  F49642-82-C-0045, 

20  August  1982.  (Unclassified) 

AFIRMS  FAR,  SofTech,  Contract  No.  MDA-903-76-C-0396,  14  March  1980. 
(Unclassified) 

AFIRMS  Data  Analysis,  SofTech,  15  February  1979.  (Unclassified) 

User's  View  of  AFIRMS,  SofTech,  1  November  1978.  (Unclassified) 


SOFfecH 


ii.  AFR  700-9,  Information  Systems  Standards,  15  March  1985.  (Unclassified) 

jj.  U.S.  Air  Force  Glossary  of  Standardized  Terms,  AFM  11-1,  Vol.  1,  2  January 
1976.  (Unclassified) 

kk.  AFIRMS  Data  Automation  Requirement  (DAR),  Final,  SofTech,  Contract  No. 
MDA-903-76-C-0396,  14  March  1980.  (Unclassified) 

11.  JCS  Memorandum  of  Policy  #172,  1  June  1982.  (Unclassified) 
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ATC 

- 

Air  Training  Command 

A  TO 

- 

Air  Tasking  Order 

ATOC 

- 

Allied  Tactical  Operations  Center  (NATO) 

BLSS 

- 

Base  Level  Self-Sufficiency  Spares 

CAFMS 

- 

Computer  Aided  Force  Management  System 

CAI 

- 

Computer-Aided  Instruction 

CAP  Report 

- 

Capability  Report 

CAS 

- 

Combat  Ammunition  System 

CBPO 

- 

Consolidated  Base  Personnel  Office 

CFMS 

- 

Combat  Fuels  Management  System 

CINC 

- 

Commander  in  Chief 

COB 

- 

Collocated  Operating  Base 

COMPES 

- 

Contingency  Operations/Mobility  Planning  and  Execution  System 

COMSEC 

- 

Communications  Security 

CONUS 

- 

Continental  United  States 

CRT 

- 

Cathode  Ray  Tube 

CSC 

- 

Combat  Support  Group 

CSMS 

- 

Combat  Supplies  Management  System 

DAR 

- 

Data  Automation  Requirement 

DBMS 

- 

Database  Management  System 

DBS 

- 

Database  Specification 

DO 

- 

Deputy  Commander  for  Operations 

D078 

- 

ARMS  (Ammunition  Reporting  Management  System) 

DOC 

- 

Designed  Operational  Capability 

DoD 

- 

Department  of  Defense 

DRD 

- 

Data  Requirements  Document 

DSDO 

- 

Data  Systems  Design  Office 

EIP 

- 

Evolutionary  Implementation  Plan 

EMSEC 

- 

Emanations  Security 

FAR 

- 

Functional  Area  Requirement 

FD 

- 

Functional  Description 

FEO 

- 

For  Exposition  Only 

FMIS 

- 

Force  Management  Information  System 

FOCAS 

- 

Force  Capability  Assessment  System 

FORSCAP 

- 

Force  Capabilities  System 

FRAG 

- 

Fragmentary  Order 
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GLCM 

- 

Ground  Launched  Cruise  Missile 

HOL 

- 

High  Order  Language 

HQ  USAF 

- 

Headquarters,  United  States  Air  Force 

HQ  USAFE 

- 

Headquarters,  United  States  Air  Forces  Europe 

HTACC 

- 

Hardened  Tactical  Air  Control  Center  (PACAF) 

IDS 

- 

Interface  Design  Specification 

IOC 

- 

Initial  Operational  Capability 

IG 

- 

Inspector  General 

ICAM 

- 

Integrated  Computer-Aided  Manufacturing 

IDEF-1 

- 

ICAM  Definition  Method  One 

IRB 

- 

Is  Referenced  By 

JCS 

- 

Joint  Chiefs  of  Staff 

3CS  MOP  172 

- 

Joint  Chiefs  of  Staff  Memorandum  of  Policy  No.  172,  "Military 
Capability  Reporting,"  1  June  1982 

JOPES 

- 

Joint  Operations  Planning  and  Execution  System 

30  PS 

- 

Joint  Operations  Planning  System 

3RS 

- 

Joint  Reporting  System 

LAN 

- 

Local  Area  Network 

LCMS 

- 

Logistics  Capability  Measurement  System 

LIMFAC 

- 

Limiting  Factor 

LMC 

- 

Logistics  Management  Center 

LOGFAC 

- 

Logistics  Feasibility  Analysis  Capability 

LOGMOD 

- 

Logistics  Module 

LPP 

- 

Learning  Prototype  Phase 

MA 

- 

Deputy  Commander  for  Maintenance 

MAC 

- 

Military  Airlift  Command 

MA3COM 

- 

Major  Command 

MDS 

- 

Mission  Design  Series 

MEI 

- 

Management  Effectiveness  Inspection 

MOB 

- 

Main  Operating  Base 

MTBF 

- 

Mean  Time  Between  Failure 

NAF 

- 

Numbered  Air  Force 

NCO 

- 

Non-Commissioned  Officer 

OPlan 

- 

Operation  Plan 

OPR 

- 

Office  of  Primary  Responsibility 

OPSTAT 

- 

Operations  Status  Report 

ORI 

OSD 

OWRM 

PACAF 

PCS 

PMO 

POE 

POL 

POM 

POS 

RCS 

RM 

SAC 

SADT 

SAM 

SECDEF 

SITREP 

SQ 

SOA 

SS 

TAC 

TACNET 

TAF 

TBD 

TFS 

TFW 

UNITREP 

USAF 

USAFE 

WIN 

WIS 

WMP 

woe 

WSAM 

WSMIS 

WWMCCS 


Operational  Readiness  Inspection 
Office  of  the  Secretary  of  Defense 
Other  War  Reserve  Materiel 
Pacific  Air  Forces 
Permanent  Change  of  Station 
Program  Management  Office 
Port  of  Embarkation 
Petroleum,  Oil  and  Lubricants 
Program  Objective  Memorandum 
Peacetime  Operating  Stock 
Reports  Control  Symbol 
Deputy  Commander  for  Resources 
Strategic  Air  Command 
Structured  Analysis  Design  Technique 
Sustainability  Assessment  Module  (Part  of  WSMIS  formerly  known  as 
Secretary  of  Defense 
Situation  Report 
Squadron 

Separate  Operating  Agency 

System  Specification 

Tactical  Air  Command 

Tactical  Air  Command  Network 

Tactical  Air  Forces 

To  Be  Determined 

Tactical  Fighter  Squadron 

Tactical  Fighter  Wing 

Unit  Status  and  Identity  Report 

United  States  Air  Force 

United  States  Air  Forces  Europe 

WWMCCS  Intercomputer  Network 

WWMCCS  Information  System 

War  Mobilization  Plan 

Wing  Operations  Center 

Weapon  System  Assessment  Model 

Weapon  System  Management  Information  System 

World  Wide  Military  Command  and  Control  System 


1.3.2  Terms  and  Definitions. 


I  Autonomous 

I  Operation 

I 

I 

Autonomous 

Operation 


Combat 

Capability 


Data 


Decision 


Deployment 


Employment 

Military 

Capability 
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(CENTO,  NATO)  One  mode  of  operation  of  a  unit  in  which  the  unit 
commander  assumes  full  responsibility  for  control  of  weapons  and 
engagement  of  hostile  targets.  This  mode  may  be  either  directed  by 
higher  authority  or  result  from  a  loss  of  all  means  of 
communication.  (3CS  Pub  1) 

(DoD,  lADB)  In  air  defense,  the  mode  of  operation  assumed  by  a 
unit  after  it  has  lost  all  communications  with  higher  echelon.  The 
unit  commander  assumes  full  responsibility  for  control  of  weapons 
and  engagement  of  hostile  targets.  (3CS  Pub  1) 

The  readiness  status  of  a  unit  to  perform  its  tasked  combat  mission 
and  its  ability  to  sustain  a  required  level  of  tasking  for  a  specified 
number  of  days.  The  terms  "Combat  Capability"  and  "Readiness  and 
Sustainability"  are  used  interchangeably  throughout  the  AFIRMS 
documents. 

(DoD)  A  representation  of  facts,  concepts,  or  instructions  in  a 
formalized  manner  suitable  for  communication,  interpretation  or 
processing  by  humans  or  by  automatic  means.  Any  representation 
such  as  characters  or  analog  quantities  to  which  meaning  is  or  might 
be  assigned.  (3CS  Pub  1) 

(CENTO,  DoD,  lADB,  NATO)  In  an  estimate  of  the  situation,  a 
clear  and  concise  statement  of  the  line  of  action  intended  to  be 
followed  by  the  commander  as  the  one  most  favorable  to  the 
successful  accomplishment  of  his  mission.  (3CS  Pub  1) 

(CENTO,  DoD,  lADB,  NATO)  In  a  strategic  sense,  the  relocation  of 
forces  to  desired  areas  of  operation.  (JCS  Pub  1) 

The  tactical  usage  of  aircraft  in  a  desired  area  of  operation.  (AFM 
11-1) 

The  ability  to  achieve  a  specified  wartime  objective  (win  a  war  or 
battle,  destroy  a  target  set).  It  includes  four  major  components: 
force  structure,  modernization,  readiness,  and  sustainability.  (JCS 
MOP  172,  1  June  1982) 

a.  Force  Structure  -  Numbers,  size,  and  composition  of  the  units 
that  comprise  our  defense  forces,  e.g.,  divisions,  ships,  airwings. 

b.  Modernization  -  Technical  sophistication  of  forces,  units,  weapon 
systems,  and  equipments. 

c.  Readiness  -  The  ability  of  forces,  units,  weapon  systems,  or 
equipments  to  deliver  the  outputs  for  which  they  were  designed 
(includes  the  ability  to  deploy  and  employ  without  unacceptable 
delays). 
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d.  Sustainability  -  The  "staying  power"  of  our  forces,  units,  weapon 
systems,  and  equipments,  often  measured  in  numbers  of  days. 
(Note:  This  is  the  part  2.  definition  of  sustainability,  which  is 
published  alphabetically.) 


Mission 


(CENTO,  NATO)  The  task  together  with  its  purpose,  thereby  clearly 
indicating  the  action  to  be  taken  and  the  reason  therefore.  The 
dispatching  of  one  or  more  aircraft  to  accomplish  one  particular 
task.  (3CS  Pub  1) 


Shortfall 


The  absence  of  forces,  equipment,  personnel,  materiel,  or  capability 
—  identified  as  a  plan  requirement  —  that  would  adversely  affect 
the  command's  ability  to  accomplish  its  mission.  (Joint  Deployment 
Agency's  Joint  Deployment  System  Procedures  Manual,  1  January  82) 


Sortie  (air) 


(CENTO,  NATO)  An  operational  flight  by  one  aircraft.  (JCS  Pub  1) 


Tasking 


(NATO)  The  process  of  translating  the  allocation  into  orders,  and 
passing  these  orders  to  the  units  involved.  Each  order  normally 
contains  sufficient  detailed  instructions  to  enable  the  executing 
agency  to  accomplish  the  mission  successfully.  (JCS  Pub  1) 


Turnaround 

(Turn) 


(DoD,  lADB,  NATO)  The  length  of  time  between  arriving 
at  a  point  and  being  ready  to  depart  from  that  point.  It  is  used  in 
this  sense  for  the  loading,  unloading,  refueling  and  rearming,  where 
appropriate,  of  vehicles,  aircraft,  and  ships.  (JCS  Pub  1) 


1.4  Introduction  to  AFIRMS.  This  section  provides  a  brief  introduction  to  the  Air  Force 
Integrated  Readiness  Measurement  System  (AFIRMS).  A  more  complete  description  is 
provided  in  the  AFIRMS  Functionai  Description. 


1.4.1  AFIRMS  Synopsis. 


1.4. 1.1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capabiiity 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to  perform 
tasked  missions  based  on  the  availability  of  specific  resources. 


The  conceptual  requirements  for  AFIRMS  are  two-fold: 


Assessment  of  combat  capability  against  specific  tasking.  The  user  can 
access  unit/force  combat  capability  against  any  planned  or  ad  hoc  tasking, 
e.g..  War  Mobilization  Plan  (WMP),  Operation  Plan  (OPlan),  Fragmentary 
Order,  Air  Tasking  Order  (ATO),  Contingency  Plan,  etc. 
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(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 

AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This  tool  permits 
comparison  of  readiness  and  sustainability  by  fiscal  year  and  can 
therefore  highlight  the  impact  of  appropriation  changes.  Thus,  changes  in 
funding  are  related  to  changes  in  force  readiness  and  sustainability.  Also, 
senior  Air  Force  decision  makers  are  supported  during  budget 
deliberations  and  Air  Force  budget  allocations. 

b.  AFIRMS  implementation  has  two  key  concepts: 

(1)  Integrated  approach  to  tasking  based  capability  assessments.  AFIRMS  has 
two  integrative  dimensions.  First,  all  applicable  resources  and  their  usage 
interactions  are  considered.  For  example,  in  sortie  capability  assessment, 
AFIRMS  evaluates  capability  in  terms  of  all  four  essential  resource  types 
(aircrew,  aircraft,  munitions,  fuel),  their  interdependencies,  and  their 
generative  components  (such  as  spares  for  aircraft,  training  qualifications 
for  aircrew,  load  crews  for  munitions,  and  hot  pits  for  fuel).  Second, 
other  automated  systems  (such  as  the  Combat  Supplies  Management 
System  (CSMS),  Combat  Fuels  Management  System  (CFMS),  Weapon 
System  Management  Information  System  (WSMIS),  etc.)  outputs  are 
integrated  into  capability  assessment  calculations  through  system 
interfaces  between  those  systems  and  AFIRMS. 

(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than  the  data 
upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a  user  orientation 
toward  quality  assurance  of  source  data.  Unit  and  other  data  input  level 
users  are  provided  effective  tools  to  accomplish  their  daily  activities  and 
therefore  develop  a  vested  interest  in  AFIRMS  data  currency  and 
validity.  Capability  assessment  data  can  then  be  extracted  for  use  by 
higher  or  parallel  users  with  maximum  confidence  in  its  validity. 


1.4.1.?  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess  readiness 
capability: 


a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system,  tasking 
must  be  converted  into  a  standard  format  recognized  by  AFIRMS.  Tasking  is 
defined  in  AFIRMS  to  the  unit  level  and  may  consist  of  actual,  hypothetical, 
standard,  or  contingency  tasking.  Any  of  these  taskings  can  be  defined  within 
specified  WMP  or  OPlan  constraints,  at  the  option  of  the  user.  Likewise,  the 
tasking  may  be  defined  by  the  user  for  present,  historic  or  future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensures  that 
information  about  inventory  status  is  available  and  accurate.  Wherever 
possible,  this  data  is  obtained  by  interface  with  other  functional  systems.  As 
with  tasking,  resource  information  can  be  defined  for  actual,  hypothetical, 
standard,  or  contingency  situations,  either  present,  historic,  or  future. 


c.  Determine  Ability  to  Perform.  Determining  the  force's  ability  to 
perform  is  the  essential  function  of  AFIRMS.  The  tasking  and 
resource  data  are  processed  to  determine  how  much  of  the  specified 
tasking  can  be  accomplished  with  the  resources  available.  Ability  to 
perform  is  evaluated  in  terms  of  the  task  metric  (sorties, etc. )  and 
the  cost  metric  (dollars)  to  provide  readiness/sustainabUity  and 
dollars  to  readiness  assessments. 

d.  Aggregate.  Analyze  and  Present  Data.  Aggregation,  analysis  and 
presentation  ensure  the  proper  grouping  and  display  of  data  to 
provide  useful  information  at  the  unit,  major  command  and  HQ  USAF. 
Aggregation  refers  to  the  creation  of  a  composite  understanding  of 
capability  for  several  units. 


1.4.2  AFIRMS  Documentation.  A  set  of  nine  types  of  documents  describes 
AFIRMS.  A  list  of  these  AFIRMS  documents  is  provided  below  along  with  a  short 
description  of  the  particular  aspects  of  AFIRMS  which  are  addressed  by  each 
document. 


a.  Functional  Description  (FD).  The  FD  provides  the  description  of 
AFIRMS  concepts  in  user  terms.  It  is  the  baseline  document  which 
ties  the  AFIRMS  documents  together. 

b.  Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It 
explains  the  cost  factors  of  AFIRMS  implementation  alternatives  and 
states  the  recommended  alternative. 

c.  Management  Plan.  The  Management  Plan  provides  the  top-level, 
integrative  frame  of  reference  for  the  AFIRMS  Program.  The  plan 
focuses  on  the  processes  which  provide  technical  and  administrative 
control  of  AFIRMS.  Key  annexes  to  the  Management  Plan  are  the 
Evolutionary  Implementation  Plan,  the  Configuration  Management 
Support  Plan,  and  the  Systems  Interface  Support  Plan. 

d.  System  Specification.  The  AFIRMS  System  Specification  adds  the 
design  requirements  to  the  functional  concepts  in  the  FD.  It  divides 
the  system  into  subsystems  (HQ  USAF,  HQ  USAFE  (MAJCQM),  and  Wing 
(unit))  and  assigns  functions  required  within  each  subsystem.  The 
system  specification  details  the  overall  architecture,  intersite 
interface  gateways,  processing  logic  flows  and  the  communications 
network  specifications. 

e.  Subsystem  Specifications.  There  are  three  AFIRMS  subsystem 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
the  Wing  (unit/squadron).  Subsystem  specifications  detail  the 

specific  design  and/or  performance  requirements  of  the  system  at  that 
level.  Design  details  cover  the  architecture,  required  functions, 
the  functional  users,  intrasite  interface  gateways,  and  applicable 
processing  logic  flows. 
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Database  Specifications.  There  are  three  AFIRMS  database 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
Wing  ( unit/ squadron ) .  These  specifications  describe  the  database 
architecture,  size  and  content,  as  well  as  logical  data  relationships 
for  the  functions  performed  at  each  of  the  AFIRMS  levels. 

Data  Requirements  Document  (DRD).  The  DRD  identifies,  categorizes, 
and  groups  the  generic  types  of  data  used  in  AFIRMS.  It  also  defines 
each  type  of  AFIRMS  data  element  (attribute  class). 

Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products 
which  implement  the  AFIRMS  functions  as  input  and  output  tools. 

Transform  and  Model  Descriptions.  The  Transform  and  Model 
Descriptions  Document  defines  how  AFIRMS  calculates  the  output  data 
from  the  input  data.  Specific  algorithmic  calculations  are  provided. 
Logical  groups  of  algorithms  forming  AFIRMS  models  and  transforms  are 
described. 


SECTION  2.  DATABASE  IDENTIFICATION  AND  DESCRIPTION 


This  section  discusses  the  information  necessary  for  identifying  and  describing  the  wing 
level  subsystem  database.  It  also  cont«iins  information  on  the  recommended  organization 
of  the  wing  database  which  is  essential  for  proper  utilization  of  the  database.  This 
section  is  intended  primarily  to  acquaint  the  AFIRMS  database  designer  with  the  overall 
issues  concerning  data  redundancy  between  and  within  sites,  speed,  and  software 
development  required  to  manage  AFIRMS  data. 


2.1  Database  Identification.  The  label  by  whir’,  the  wing  level  database  is  uniquely 
identified  includes  the  wing  number,  the  wing  mission  type,  and  "DB"  as  a  suffix  (e.g., 
52TFWDB  for  52nd  Tactical  Fighter  Wing  database). 


2.1.1  System  Using  the  Database.  The  system,  of  which  the  wing  level  database  is  part, 
is  the  Air  Force  Integrated  Readiness  Measurement  System  (AFIRMS). 


2.1.2  Storage  Requirements.  A  method  for  estimating  the  database  storage  requirements 
for  the  wing  level  site  of  AFIRMS  is  discussed  in  this  section. 

Shown  below  is  an  example  of  information  that  is  collected  for  each  Appearance 
Class  listed  in  the  DRD,  stored  at  the  wing,  and  used  to  calculate  an  appropriate  sizing 
estimate.  This  example  is  an  excerpt  from  the  list  given  in  Appendix  A. 


APPEARANCE 

NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

TOTAL 

SIZE 

IIB 

AIRCRAFT  SERIAL  NUMBER 

8 

80 

3840 

12A 

AIRMAN  LAST  NAME 

16 

216 

20736 

From  left  to  right  are  listed  the  appearance  number  of  each  item  in  question,  its 
name,  and  other  information  pertaining  to  its  storage  in  the  central  database.  Some 
appearance  class  names  have  a  brief  description  included  to  identify  the  assumptions 
behind  the  quantity. 
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Aircraft  Serial  Number  describes  an  individual  aircraft.  The  next  column,  size, 
indicates  maximum  length  in  bytes  of  the  appearance.  For  alpha  or  alphanumeric  data 
types,  size  equals  the  maximum  length  possible  for  that  appearance.  Use  of  the  maximum 
length  results  in  worst-case  database  sizing  estimates.  An  alternative  method  or 
estimating  that  size  employs  an  average  length  of  AFIRMS  character  data.  Another 
approach  is  to  assume  that  all  character  data  is  stored  with  the  use  of  a  compression 
algorithm.  These  alternatives  are  evaluated  during  the  Analysis  Phase  of  the  initial  block 
of  each  segment  before  the  final  database  sizing  estimate  is  given.  In  the  case  of  numeric 
data,  i.e.,  real  or  integer  values,  size  is  set  equal  to  4  bytes.  Quantity,  the  next  column, 
indicates  how  many  instances  of  the  appearance  exist  in  the  site's  central  database. 

In  the  sample  table  above,  if  there  were  80  aircraft,  to  be  monitored  and  stored  in 
the  site's  central  database,  then  the  aircraft  serial  number  is  stored  80  times.  Similarly, 
if  there  were  216  airmen  at  a  base,  216  ciirman  last  names  would  be  stored  in  the  central 
database.  The  final  column,  total  space,  reflects  the  total  space  necessary  to  store  that 
appearance  class  in  the  site's  central  database.  This  figure  is  derived  from  the  maximum 
length  multiplied  by  the  quantity.  This  result  is  then  multiplied  by  a  factor  of  6.  The 
multiplication  factor  of  6  represents  the  actual  storage  for  the  appearance  plus  storage 
space  for  a  combination  of  5  historical  or  "what-if"  copies  of  the  appearance.  The  sum  of 
the  total  space  needed  over  the  entire  Appendix  A  listing  yields  total  space  required  for 
the  central  database. 


In  Appendix  B,  the  sizing  process  is  accomplished  for  each  functional  area  for  the 
wing  participating  in  AFIRMS.  Note  that  the  estimates  in  Appendix  B  must  also  be 
refined  depending  on  the  degree  of  data  redundancy  required  by  the  data  management 
software  selected  for  implementation.  Both  software  selection  and  final  sizing  occur 
during  the  analysis  phase  of  the  initial  block  of  each  segment.  Table  2-1  contains  the 
numbers  actually  used  to  compute  the  database  sizings  for  an  operational  AFIRMS  at  the 
Wing  level. 


The  database  sizing  estimates  presented  in  the  HQ  USAFE  Database  Specification  are 
based  on  the  assumption  that  the  MAJCOM's  Fighter/Reconnaissance  resources  are 
augmented  during  crises  situations  by  numerous  CONUS  units.  As  a  result,  the  database 
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Table  2-1 


WING  OPERATIONAL  DATABASE  SIZING  FACTORS 


(1) 

(2) 

(3) 

(4) 

(5) 

OPS 

30 

9 

30 

123 

232 

woe 

40 

22 

55 

141 

267 

MOC 

12 

14 

117 

188 

355 

AMU 

6 

11 

183 

237 

448 

MUN  CTL 

11 

10 

91 

168 

318 

FUELS  CTL 

9 

8 

89 

167 

316 

SUPPLY 

4 

0 

0 

100 

189 

TOTAL  WING 

40 

22 

55 

144 

266 

LEGEND: 


Col-1  represents  the  total  number  of  screens  used  by  a  specific  functional  area  during 
the  LPP. 

Col-2  represents  the  total  number  of  new  screens  used  by  a  specific  functional  area 
during  operational  AFIRMS. 

Col-3  represents  the  percentage  increase  of  new  screens  over  those  used  during  the 
LPP  (i.e.,  Col-2  divided  by  Col-1  times  100). 

Coi-4  represents  the  original  database  size  (as  a  percentage)  plus  the  percentage 

increase  of  the  database  size  due  to  the  new  operational  screens.  It  is  assumed 
that  all  new  screens  will  use  23%  of  the  data  already  existing  in  the  database. 
The  remaining  73%  of  data  used  by  the  new  screens  is  estimated  to  be  new. 
Note  that  the  73%  new  data  must  be  applied  to  the  percentage  of  new  screens 
(Col- 3)  to  obtain  the  actual  percentage  increase  in  size  of  the  database  (i.e., 
multiply  Col-3  by  0.75  by  100). 

Col-5  represents  the  percentage  increase  in  the  size  of  the  database  when  the  five 
additional  factors  shown  below  are  accounted  for  in  addition  to  Col-4: 


a. 

0.75- 

CO  mpression/encoding. 

b. 

1.01  - 

time  stamping  at  the  record  level. 

c. 

1.01  - 

editing/validition  data. 

d. 

1.65- 

typical  DBMS  miscellaneous  data  overhead  requirement. 

e. 

1.50- 

key  propagation  required  for  a  relational  DBMS  implementation. 

The  first  factor  tends  to  decrease  database  size;  though  the  others  all  increase 
database  size.  When  these  factors  are  multiplied  together,  a  combined  factor  of 
1.S9  is  generated.  That  is  an  S9%  increase  in  database  size.  To  determine  the 
actual  percentage  increase,  we  must  multiply  Col-4  by  1.89  by  100.  This 
percentage  increcise  is  applied  to  all  database  size  estimates  mentioned  on 
subsequent  pages  to  determine  the  estimated  operational  database  size  for  each 
functional  area  and  the  central  database. 
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The  wing  database  sizing  requirements  should  also  be  increased  based  on  this 
assumption.  The  baisic  question  is  "How  much  should  the  wing  database  sizing  be 
increased?”  While  the  worst-case  sizing  estimates  for  HQ  USAFE  are  determinable  and 
justifiable  without  specific  wing  bed-down  plans,  any  wing  database  sizing  which  does  not 
consider  worst-case  senario  is  invaiid. 

It  is  reasonable  to  assume  that,  during  crises,  what-if  versions  of  the  central  and 
functional  area  databases  are  off-loaded  to  provide  sufficient  space  to  accommodate 
augmentation.  However,  the  best  solution  is  to  first  determine  the  worst-case 
augmentation  plan,  and  subsequently  use  that  plan  to  determine  the  actual  database  size 
for  various  wings  in  the  MA3COM.  This  requirements  analysis  and  sizing  determination  is 
an  integral  part  of  the  Analysis  Phase  of  initial  blocks  for  each  segment. 

Each  AFIRMS  site  has  a  parameter  accessible  by  a  system  manager  that  controls  the 
number  of  copies  of  what-if  databases  by  functional  area.  As  use  of  the  system  increases, 
this  parameter  can  be  used  as  a  tuning  mechanism  to  increase  or  decrease  the  number  of 
on-line  copies  of  what-if  databases  by  functional  area  in  order  to  manage  available  disk 
space.  The  value  of  this  parameter  is  set  to  3  for  the  database  sizing  estimates  of  this 
document. 


The  growth  of  the  Wing  level  database  is  estimated  as  approximately  10%  per  year. 
This  estimate  is  less  than  the  other  command  levels  because  the  number  of  additional 
users  possible  is  not  as  great.  The  capability  for  on-line  storage  of  one  copy  of  real  data 
along  with  five  copies  of  what-if  data  is  required  at  the  wing  level  to  accommodate 
readiness  assessment.  The  five  copies  maintained  on-line  support  the  following  estimated 
requirements  for  copies  of  data. 

Exercises  (1  beginning  copy,  I  end  copy) 

Ad-hoc  what-ifs  (3  copies) 

DOC  what-ifs  (3  copies). 
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Sizing  estimates  conform  to  the  assumption  that  the  AFIRMS  database  architecture 
at  the  wing  level  is  one  of  attribute  segmentation  which  yields  "worst-case"  estimates  at 
the  functional  areas.  In  this  architecture,  each  functional  area  is  responsible  for  its  own 
data.  A  copy  of  all  functional  area  data  resides  in  a  centralized  database,  probably  the 
Wing  Operations  Center  (WOC),  duplicating  data  for  the  functional  areas.  Data  that  is 
normally  used  by  a  given  functional  area  resides  at  that  functional  area  with  updates 
transmitted  to  and  from  the  central  database.  If  data  that  is  not  resident  at  a  given 
functional  area  is  required  at  that  functional  area,  then  that  data  is  downloaded  to  that 
location  along  with  software  needed  to  access  it.  The  degree  of  redundancy  necessary 
must  be  determined  before  final  sizing  estimation.  Following  the  determination  of  a 
functional  area's  sizing  estimate,  the  number  of  what-if  databases  to  be  maintained 
on-line  is  specified.  Finally,  the  actual  data  and  its  redundancy  within  a  site  for  real  and 
what-if  purposes  is  determined.  These  issues  are  addressed  by  the  database  designer  in 
the  Analysis  Phase  of  the  initial  block  of  each  segment  for  accurate  sizing  estimates. 
Estimates  given  in  Appendices  A  and  B  are  provided  for  planning  purposes. 

Until  the  actual  DBMS  is  chosen,  the  estimates  shown  in  Appendices  A  and  B,  with 
some  refinement,  suffice  as  a  starting  point  in  most  economic  considerations  as  well  as 
high-level  design  decisions.  It  can  also  be  used  as  a  tool  in  the  comparison  of  different 
DBMSs.  When  an  actual  DBMS  is  chosen,  those  factors  indigenous  to  the  data  model  and 
the  particular  DBMS  are  used  for  calculating  a  more  refined  space  requirement  estimate. 
After  final  data  requirements  are  determined  during  the  Analysis  Phase  of  each  segment, 
sizing  requirements  will  probably  be  lower  for  the  functional  areas  than  estimated  in 
Appendix  B. 

2.1.3  Physical  Description  of  the  i-.atabase  Files.  The  master  file(s)  containing  the  wing 
level  database  are  stored  on-line  on  non-volatile  random  access  mass  storage  media  with 
back-ups  off-line  on  magnetic  tape  or  floppy  disk. 

2.2  Organization  of  the  Database.  There  are  many  differences  between  a  database  design 
in  the  classical  sense  where  a  DBMS  is  chosen  and  a  schema  (or  logical  design)  is 
developed,  and  the  design  of  the  AFIRMS  databases.  AFIRMS  can  accommodate  many 
different  DBMSs  and  schemas.  Complexities  arise  because  AFIRMS  resides  at  three 
different  levels  of  the  command  structure.  Standard  database  issues  such  as  security,  ad 


hoc  query  capability,  and  data  communications  become  very  complicated  when  the  ability 
to  receive  and  transmit  data  between  sites  is  considered  the  basis  of  the  system.  During 
the  Analysis  Phase  of  the  initial  block  of  each  segment,  the  database  designer  must  be 
aware  of  these  problems  and  realize  that  the  design  of  the  database  at  each  level  is 
dependent  upon  the  other  levels. 

The  design  of  the  AFIRMS  database  will  support  the  requirements  for  an  interactive 
query  capability  accessing  current,  historical,  and  hypothetical  (what-if)  data.  Historical 
data  resides  on  off-line  media  and  is  copied  to  on-line  media  on  an  "as-needed"  basis.  In 
order  to  accommodate  this  and  to  minimize  the  amount  of  time  necessary  to  develop 
applications,  a  commercial  DBMS  software  package  i.e.,  "off  the  shelf,"  is  utilized.  It 
should  also  be  noted  that  not  all  site  data  management  requirements  can  be  met  by  a 
single  DBMS.  A  DBMS  may  be  resident  at  the  central  location  of  each  site  along  with  any 
other  software  necessary  to  manage  the  data  at  the  functional  areas.  The  database  that 
the  DBMS  operates  upon  resides  primarily  on  non-volatile  random  access  media  with 
backups  and  copies  residing  on  non-volatile  media. 

The  data  model(s)  used  in  a  particular  segment  is  determined  during  the  Analysis 
Phase  of  the  initial  block  of  each  segment.  As  a  result,  the  DBMS  used  for  the  central 
database  and  the  data  management  software  at  each  functional  area  for  each  segment  are 
unknown  as  is  the  actual  physical  structure  of  that  data  as  it  will  exist  on  disk  and  tape 
media. 


There  are  three  basic  requirements  of  AFIRMS  at  the  wing  level  that  relate  to  the 
choice  of  a  DBMS  and  the  design  of  the  database.  They  are  reliability/availability, 
deployability,  and  reportability. 


The  basic  long-term  requirements  include: 


a.  Reliability/Availability.  Reliability/Availability  is  the  ability  of  the  system  to 
be  accessible  to  all  users  and  for  the  accuracy  of  AFIRMS  data  to  be  very  high 
during  peacetime  and  crises.  Survivability  during  wartime  is  not  presently  a 
requirement  for  operational  AFIRMS. 

b.  Deployability.  Deployability  is  the  ability  of  a  functional  user  or  unit  to  deploy 
and  connect  to  an  operating  AFIRMS  at  the  deployed  locatiori.  The  data 
necessary  to  service  the  individual  user  unit  is  the  responsibility  of  the 
functional  area  or  unit.  Deployed  units  have  the  capability  to  report,  at  a 
minimum,  to  the  AFIRMS  system. 
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c.  Reportability.  Reportability  is  the  ability  of  a  unit  or  functional  area  to  report 
its  status  upward  to  the  parent  unit  regardless  of  its  current  location.  When  the 
reporting  unit  is  able  to  connect  to  an  operating  AFIRMS  not  within  its  parent 
wing  or  MAJCOM,  AFIRMS  provides  the  capability  to  transmit,  at  a  minimum, 
status  of  the  reporting  unit  to  the  parent  database. 


2.2.1  Database  Architecture  Options.  In  order  to  arrive  at  an  acceptable  database 
architecture  to  support  AFIRMS  at  the  wing,  a  number  of  feasible  database  architectures 
were  evaluated  in  terms  of  the  requirements  outlined  in  the  previous  section  as  well  as 
hardware  and  software  development  costs,  performance,  and  maintainability.  These 
alternatives  were  also  evaluated  in  terms  of  system  expandability  without  modification  to 
the  data  structure  and  software. 


The  AFIRMS  database  architecture  supporting  the  Wing  is  designed  to  operate  in 
normal  peacetime  conditions  and  crises.  Two  conceptual  database  architectures  that 
were  evaluated  include  data  centralization  (2.2. 1.1  below)  and  data  distribution  (2.2. 1.2). 
A  brief  explanation  of  each  of  these  is  provided  in  the  following  sections.  These 
explanations  are  intended  to  give  a  summary  of  the  conceptual  database  architectures, 
but  are  not  intended  to  imply  that  a  copy  of  a  DBMS  should  reside  at  each  functional 
area.  Nor  do  they  imply  that  any  particular  data  management  or  file  system  should  be 
employed  to  manage  the  data  at  each  functional  area.  The  primary  requirement  is  that  if 
data  is  required  to  be  resident  at  a  functional  area,  software  must  also  be  present  to 
handle  it,  and  to  manage/control  concurrency  problems  that  occur. 

In  general,  the  operating  costs  of  a  database  consist  of  storage  costs  of  file  copies 
and  communications  costs  for  queries  and  updates.  High  redundancy  tends  to  decrease 
communications  costs  for  queries  because  data  is  local  to  the  user.  However,  high 
redundancy  increases  storage  and  communications  costs  for  updates  because  many  files 
are  affected  by  the  update  of  one  version.  Low  redundancy  has  the  opposite  tendency. 
Cost/benefit  analysis  using  high  and  low  redundancy  is  of  major  importance  in  the 
database  architecture  selection  process. 


2.2. 1.1  Data  Centra  ration.  Total  centralization  of  data  was  the  database  architecture 
employed  in  the  AFIRMS  LPP  for  the  prototype  databases.  All  of  the  data  used  by  the 
system  resides  on  a  central  computer  under  the  management  of  a  single  DBMS.  Some 
transactions  that  occur  have  proven  to  be  quite  burdensome  on  the  central  computer.  The 
degree  to  which  the  Central  Processing  Unit  (CPU)  is  dominated  by  the  DBMS  is  termed 
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CPU-boundedness  and  can  be  tuned  more  or  less  with  DBMS  system  parameters. 

However,  LPP  applications  software  resident  on  the  central  computer  was  also  highly 
CPU-bound.  This  caused  competition  for  CPU-time  when  more  than  one  transaction  was 
executed  at  a  time  and  the  DBMS  CPU  demands  compounded  the  problem.  The  DBMS  can 
be  adjusted  to  lower  its  demand  for  CPU  but  the  cost  is  an  increase  in  its  need  for 
input/output.  Thus  a  CPU  bottleneck  becomes  an  input/output  bottleneck.  The  result  is 
that  the  transactions  become  queued  waiting  for  disk  access. 

In  a  centralized  processing  environment,  CPU-boundedness  is  to  be  expected.  In  this 
situation,  the  most  straightforward  solution  is  a  larger  and  faster  computer.  However, 
this  is  relatively  expensive  in  light  of  the  many  sites  AFIRMS  intends  to  support. 
I/O-bound  processing  is  likely  to  occur  with  architectures  using  a  back-end  database 
machine  because  processes  in  the  main  computer  would  become  queued  while  others  finish 
in  the  database  processor. 

A  centralized  database  at  the  wing  level  is  a  very  vulnerable  system  in  the  event  of 
hardware  failure  bacause  of  their  single  location.  AFIRMS  is  unavailable  during  such 
failures.  Reportability  also  suffers  when  the  central  database  is  unavailable.  Conversely, 
software  development  and  maintenance  costs  are  usually  at  their  lowest  with  this 
architecture  because  all  of  the  software  and  data  reside  at  a  single  location. 

High-powered  hardware  would  be  required  at  the  central  location,  but  dumb  terminals 
would  suffice  for  support  of  the  functional  areas. 

2.2. 1.2  Data  Distribution.  Five  variations  of  data  distribution  were  evaluated;  full 
redundancy  (2.2. 1.2.1  -  below),  entity  redundancy  (2.2. 1.2.2),  attribute  segmentation 
(2. 2. 1.2. 3),  record  or  tuple  segmentation  (2.2. 1.2.4),  and  record/attribute  segmentation 
(2.2. 1.2.5).  Conceptually,  each  variation  could  be  implemented  with  or  without  a 
redundant  master  copy  of  data  residing  at  a  central  location.  This  master  copy  is  the 
equivalent  of  the  union  of  all  the  functional  areas'  databases.  A  distributed  data 
implementation  without  the  inclusion  of  a  master  copy  was  deemed  too  costly  and 
unreliable.  Another  disadvantage  is  that  there  are  currently  no  distributed  DBMSs 
available  commercially. 


I 


Each  variation  discussed  is  based  on  the  assumption  that  there  is  a  central  database 
at  with  a  varying  degree  of  data  redundancy  at  the  functional  areas.  A  common  thread 
exists  among  the  variations.  Updates  to  data  are  made  at  a  functional  area,  transmitted 
to  the  central  database,  and  subsequently  transmitted  to  all  affected  functional  areas 
where  final  updates  occur.  After  each  variation  is  evaluated  relative  to  the  others,  a 
conclusion  is  reached  concerning  its  feasibiltiy  for  operational  AFIRMS. 

Certain  advantages  are  inherent  to  an  architecture  with  a  centralized  database.  A 
degree  of  interface  control  is  available  in  that  both  magnetic  tape  and  direct-line 
interfaces  to  other  systems  can  occur  at  the  central  location  and  data  can  then  be 
downloaded  to  the  appropriate  functional  area(s).  The  same  advantage  works  for  systems 
desiring  access  to  AFIRMS  data.  Also,  periodic  database  backups  occur  more  cleanly  and 
with  minimal  impact  on  the  system.  Again,  if  the  central  location  is  incapacitated,  these 
capabilities  may  be  hindered  if  not  eliminated.  However,  the  inherent  contingency 
capability  provided  by  this  architecture  provides  for  standalone  AFIRMS  operations  in  the 
functional  areas  as  a  minimum. 

Reportability  is  accomplished  relatively  easily  if  the  central  location  is  operating, 
and  less  smoothly  from  a  functional  area  wh^n  it  is  down.  Deployment  of  units  or 
functional  areas  is  facilitated  with  the  unplug-upon-departure  and  plug-in-upon-arrival 
capability  inherent  to  a  centralized  distributed  architecture.  Units  or  functional  areas 
can  also  transfer  copies  of  their  local  database  to  floppy  disk  or  magnetic  tape  and  take 
them  for  use  at  the  new  site. 

Although  a  data  distribution  architecture  with  a  central  database  does  combine  some 
of  the  advantages  of  the  distributed  and  centralized  concepts,  there  are  also  some 
disadvantages  to  the  data  distribution  architecture.  Specifically,  more  intelligent 
software  is  required  to  manage  the  distributed  data.  A  disadvantage  of  total  data 
centralization  also  present  with  this  architecture  is  the  centralization  of  both 
communications  and  data.  Since  all  site  data  communications  must  be  routed  through  the 
central  database,  AFIRMS  is  only  as  reliable  as  the  central  location  of  its  database. 

In  the  event  that  the  central  location  goes  down,  the  functional  areas  cannot  receive 
data  updates  from  other  functional  areas  through  the  system  and  would  have  to  resort  to 
manual  communications.  With  local  data  entry  using  manually  retrieved  information,  the 
user  has  full  use  of  AFIRMS  tools  normally  available.  From  a  system  point  of  view,  if  the 


central  location  at  a  particular  site  goes  down,  that  site  is  not  functioning  within 
AFIRMS.  At  MAJCOM  and  Wing  levels  a  back-up  communications  mode  is  available 
through  which  one  or  more  of  the  functional  areas  operating  independently  of  each  other 
can  communicate  with  the  next  higher  central  location.  However,  the  MAJCOM  cannot 
receive  Wing  reports  if  the  MA3COM  central  location  is  inoperable. 


The  depth  of  this  problem  is  to  be  studied  further  in  the  Analysis  Phase  ol  each 
segment,  to  fully  understand  the  interdependencies  of  functional  areas  and  the  percentage 
of  data  affected  when  a  central  location  goes  down.  Appendix  B  lists  data  that  is  used  by 
the  functional  area  at  the  Wing  level.  During  the  Analysis  Phase  of  each  segment, 
Appendix  B  is  refined  to  include  its  current  cross-reference  between  a  data  item  and  the 
functional  area(s)  using  that  data  item  and  also  that  data  item's  range  of  values  allowed 
at  that  functional  area. 


2.2. 1.2.1  Full  Redundancy.  Full  redundancy  calls  for  all  site  data  to  be  resident  at  each 
functional  area.  One  advantage  to  this  architecture  is  that  software  developed  to  support 
one  functional  area  can  support  all  functional  areas  with  minimal  changes.  Another  is 
that  each  functional  area  can  operate  independently  in  the  event  that  some  data  from 
other  functional  areas  is  inaccessible.  It  may  be  that  some  functional  areas  will  be  forced 
to  operate  in  a  degraded  mode  with  the  data  current  as  of  the  outage.  Reportability  is 
also  very  strong  in  this  situation,  since  data  can  be  generated  and  received  at  almost  any 
functional  area  that  survives.  The  disadvantages  include  a  marked  increase  in  required 
storage  capacity  at  all  functional  areas  and  increased  communications  traffic  whenever 
updates  occur,  making  this  alternative  unfeasible. 


2.2. 1.2.2  Entity  Redundancy.  Entity  redundancy  is  based  on  the  assumption  that  if  a 
functional  area  requires  any  use  of  a  particular  data  attribute  (field),  the  attribute,  along 
with  its  associated  attributes  grouped  within  entity  classes,  resides  at  the  functional 
area.  This  redundancy  exists  regardless  of  whether  the  entire  entity  class  is  used  by  the 
functional  area.  Updates  to  the  data  attributes  within  the  entity  classes,  when  initiated 
by  other  functional  areas,  are  transmitted  from  the  central  location.  The  possible  result 
is  unnecessary  communication  and  data  storage  costs. 
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For  example,  Figure  2-1  shows  an  excerpt  of  Aircraft-oriented  data  grouped  in  table 
format.  Included  are  the  AIRCRAFT  NUMBER,  AIRCRAFT  OWNING  UNIT,  AIRCRAFT 
STATUS,  AIRCRAFT  LOCATION,  and  the  AIRCRAFT  CONFIGURATION.  All  columns 
(attributes)  in  the  table  describe  a  particular  aircraft,  hence,  what  is  shown  is  the 
AIRCRAFT  entity  class.  In  entity  redundancy,  all  columns  of  an  entity  reside  at  the 
81TFS  if  that  squadron  needs  to  view  any  of  the  columns. 
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Figure  2-1.  Entity  Redundancy 


2.2. 1.2.3  Attribute  Segmentation.  Attribute  segmentation  is  a  further  refinement  of 
entity  redundancy.  Accordingly,  this  alternative  is  based  on  the  assumption  that  only 
relevant  entity  classes  reside  at  a  functional  area.  Of  those  entity  classes,  only  those 
attributes  that  are  used  by  the  functional  area  reside  there.  This  concept  further  reduces 
functional  area  storage  requirements  and  communication  costs  between  the  functional 
area  and  the  central  location.  However,  this  reduction  is  accommodated  only  by  greater 
processing  requirements  at  the  central  location.  Software  is  required  at  the  functional 
areas  and  the  central  location  in  order  to  handle  the  logic  required  for  transmitting  and 
receiving  the  updates  to  certain  data  attributes. 

This  alternative  is  recommended  to  be  the  initial  database  architecture  for  AFIRMS 
due  to  its  relatively  lower  software  development  and  physical  storage  costs.  However, 
there  is  still  the  possibility  that  the  data  redundancy  inherent  to  this  architecture  causes 
unnecessary  communications  and  storage  costs.  Unnecessary  in  the  sense  that  there  are 
values  of  attributes  (residing  at  functional  areas)  that  are  never  used.  Consequently, 
these  attributes  are  updated  upon  change  by  the  owning  functional  area.  Software 
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development  costs  are  quite  lower  than  for  record  segmentation  and  record/attribute 
segmentation,  and  not  much  greater  than  for  full  or  entity  redundancy.  Storage  costs  are 
much  less  than  for  full  and  entity  redundancy  and  relatively  equal  to  costs  for  record 
segmentation.  However,  storage  requirements  are  somewhat  greater  for  attribute 
segmentation  than  for  record/attribute  segmentation.  Attribute  segmentation  can  also  be 
gradually  evolved  into  a  record/attribute  segmentation  architecture  by  adding  a  layer  of 
software  and  instituting  virtually  no  changes  to  the  existing  software. 


Figure  2-2  shows  an  example  of  attribute  segmentation.  In  this  example,  the  81TFS 
only  needs  to  view  the  AIRCRAFT  NUMBER  (which  is  the  key  to  the  entity),  AIRCRAFT 
OWNING  UNIT,  AIRCRAFT  STATUS,  and  the  AIRCRAFT  LOCATION  (all  shown  in  the 
highlighted  boxes).  Note,  however,  that  the  81TFS  database  still  contains  information 
pertaining  to  other  squadrons. 
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Figure  2-2.  Attribute  Segmentation 


2.2. 1.2.4  Record  or  Tuple  Segmentation.  Record,  or  tuple  in  a  relational  implementation, 
segmentation  is  also  a  further  refinement  of  entity  redundancy.  Only  those  records  that 
possess  keys  with  relevant  values  reside  at  the  functional  area.  Storage  and 
communications  costs  are  significantly  lower  than  for  full  or  entity  redundancy 
implementation.  These  costs  are  relatively  equal  to  attribute  segmentation  storage  and 
communications  costs,  but  the  software  required  to  manage  data  communications  is 
somewhat  more  complex.  Storage  costs  are  greater  than  for  a  record/attribute 
segmentation  implementation,  but  the  software  development  required  is  less  complex. 
There  also  possibly  exists,  with  this  alternative,  unnecessary  data  at  the  functional 
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areas  that  must  incur  storage  costs  and  communications  costs  to  update  it.  Furthermore, 
record  segmentation  is  far  more  complex  to  implement  than  attribute  segmentation  and 
is,  therefore,  deemed  less  feasible. 


Figure  2-3  shows  an  example  of  record  segmentation.  Note  that  records  about 
aircraft  assigned  to  the  81TFS  are  the  only  aircraft  records  of  interest  to  the  81TFS. 
Therefore,  with  this  architecture,  only  the  81TFS  aircraft  records  are  present  in  the 
Aircraft  entity  when  it  resides  at  the  81TFS  as  shown  by  the  highlighted  box.  As  a  result, 
all  columns,  or  attributes,  of  each  record— some  of  which  may  not  be  used— reside  in  the 
81TFS  database.  In  this  example,  the  attribute  AIRCRAFT  CONFIGURATION  is  not  used 
by  the  squadron  but  still  resides  there. 
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Figure  2-3.  Record  or  Tuple  Segmentation 


2«2. 1.2.3  Record/ Attribute  Segmentation.  This  architecture  is  another  refinement  of 
entity  segmentation,  and  employs  the  concepts  of  attribute  and  record  segmentation. 

Only  those  records  that  possess  keys  with  relevant  values,  such  as  in  record  segmentation, 
and  only  those  relevant  attributes  within  each  record  or  tuple  reside  at  a  functional  area 
such  as  in  attribute  segmentation.  In  essence,  this  architecture  is  the  result  of  the 
intersection  of  the  attribute  and  record  segmentation  concepts.  Figure  2-4  shows  an 
example  of  attribute/record  segmentation.  The  81TFS  only  has  data  that  it  needs  to  view 
present  in  its  database,  as  shown  by  the  highlighted  box. 
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With  this  alternative,  storage  and  communications  costs  are  minimized.  But  the 
functional  area  is  still  able  to  operate  independently  in  a  degraded  mode.  However, 
software  development  and  processing  costs  at  the  central  location  are  highest  with  this 
alternative.  Record/Attribute  segmentation  should  be  the  ultimate  goal  of  the  AFIRMS 
database  architecture,  but  it  is  unfeasible  to  implement  in  the  initial  block  due  to  high 
data  analysis  and  software  development  costs.  This  architecture  can  be  reached  through 
an  evolutionary  implementation  from  the  attribute  segmentation  architecture,  if  desired 
with  minimal  changes  to  existing  software. 
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Figure  2-4.  Record/Attribute  Segmentation 


2.2.2  AFIRMS  Database  Architecture.  During  the  Analysis  phase  of  the  initial  block  of 


each  segment  it  is  to  be  determined  which  of  the  two  architectures,  attribute  segmentation 
or  record/attribute  segmentation,  will  be  implemented  MAJCOM-wide.  The  choice  will  not 
affect  other  MAJCOMs  or  HQ  USAF  since  record/attribute  segmentation  is,  actually,  a 
more-refined  attribute  segmentation  approach.  It  may  be  that  an  architecture  employing 
record/attribute  segmentation  is  the  ultimate  goal  of  the  AFIRMS  database  design  in  a 
particular  MAJCOM,  but  attribute  segmentation  is  desirable  initially.  This  approach  will 
allow  more  functional  areas  within  a  Wing  to  become  operational  earlier,  and  will  permit 
more  time  for  analysis  of  data  requirements  of  individual  functional  areas.  A  database 
architecture  using  attribute  segmentation  is  more  readily  adaptable  to  an  orderly 
accommodation  of  functional  requirements,  from  a  database  design  and  software 
development  point  of  view.  These  additional  data  needs  are  accommodated  by  trading  off 
the  more  global  view  in  favor  of  a  more  specifically  relevant  local  view. 


Assuming  attribute  segmentation  is  used  initiaJiy,  a  central  location  houses  a  copy  of 
the  database.  Each  functional  area  that  participates  in  AFIRMS  also  has  a  database 
locally  resident  on  its  own  AFIRMS  hardware.  In  general,  the  characteristics  of  the  data, 
as  well  as  the  data  structures  and  relationships,  are  identical  wherever  they  reside  at  the 
wing.  This  is  true  regardless  of  the  data  management  or  database  management  software 
employed,  provided  the  conceptual  data  models,  such  as  the  IDEF-1  model  shown  in  the 
Data  Requirements  Document,  used  by  the  software  are  identical. 

For  example,  in  Figure  2-5  a  simplified  Wing-level  database  is  shown  to  include  three 
different  entity  classes  in  the  central  databcise:  Air  Force  Unit,  Aircraft,  and  Airman. 
Note  the  relationships  of  the  entity  classes:  an  Air  Force  Unit  has  one  or  more  Aircraft 
assigned  to  it  and  one  or  more  Airmen  assigned  to  each  unit.  In  this  case,  two  functional 
areas,  the  Wing  Operations  Center  (WOC)  and  the  Aircraft  Maintenance  Unit  (AMU),  use 
all  or  parts  of  the  central  database;  hence,  all  or  parts  of  the  central  database  reside  at 
the  two  functional  areas  for  speed  of  access.  The  WOC  needs  to  view  products  that  use 
unit,  aircraft,  and  airman  data;  but  the  AMU  only  view  products'  that  use  unit-  and 
aircraft-specific  data.  The  data  that  resides  in  both  functional  areas  heis  characteristics 
and  relationships  identical  to  the  data  that  resides  in  the  central  database.  If  a  particular 
aircraft  is  repaired  and  its  status  is  updated  by  the  AMU  to  indicate  such,  then  that 
update  is  transmitted  to  the  central  database,  where  the  aircraft  record  is  updated. 
Finally,  the  updated  aircraft  information  is  transmitted  to  the  WOC. 

By  retaining  the  same  conceptual,  logical,  and  physical  data  models  throughout  a 
segment  within  the  EIP  implementation  of  the  following  areas  is  enhanced: 

1)  data  analysis  in  the  Analysis/Requirements  Definition  Phase; 

2)  software  development  in  the  Development  Phase; 

3)  installing  software,  testing  software,  and  training  in  the  Installation  Phase; 

4)  software  and  database  maintenance  in  the  Operations  Phase. 

2.3  Special  Instructions.  This  section  describes  the  desired  capabilities  of  AFIRMS 
including  data  currency,  ad  hoc  query,  what-if  capability,  reporting,  backup,  archiving, 
and  restoration  as  well  as  issues  concerning  data  redundancy,  external  interfaces, 
normalization,  and  data  models.  Suggestions  are  made  in  these  areas  and  information  and 
guidelines  are  given  to  aid  in  the  selection  of  a  DBMS  and  other  data  management 
software  for  implementation  at  a  specific  site. 


2.3.1  Data  Currency.  When  changes  are  made  to  data  at  the  functional  area  level,  those 
changes  are  transmitted  to  the  central  database.  After  the  central  database  is  updated, 
the  changes  are  subsequently  transmitted  to  other  functional  areas  having  the  data  in 
question  resident  on  their  local  database.  The  time  required  to  complete  the  transactions 
on  the  central  database  and  all  affected  functional  areas  determines  the  currency  of  data. 

At  a  wing,  this  time  period  must  be  less  than  three  minutes  for  AFIRMS 
mission-related  data  90%  of  the  time  with  the  system  operating  in  a  normal  mode. 
AFIRMS  mission-related  data  consists  of  current  tasking,  and  current  primary  resource 
status  information  or  that  data  associated  with  a  crisis  mode.  Primary  resources  are 
those  resources  directly  utilized  by  the  capability  assessment  model. 

Data  currency  at  a  wing,  must  be  achieved  within  one  hour  for  AFIRMS 
non-missions-related  data  90%  of  the  time  with  the  system  operating  in  a  normal  mode. 
AFIRMS  non-mission-related  data  consists  of  that  information  relating  to  ad-hoc,  historic, 
exercise,  or  contingency  simulations  which  are  not  designated  as  current  exercises/crises. 

Data  currency  between  the  WING  and  MAOCOM  level  must  be  achieved  within  six 
hours  90%  of  the  time  when  the  system  is  operating  in  normal  mode.  Data  currency 
between  the  MA3COM  and  HQ  USAF  level  is  achieved  within  twelve  hours  90%  of  the 
time  when  the  system  is  operating  in  normal  mode. 

2.3.2  Ad  Hoc  Query.  Users  need  to  execute  ad  hoc  queries  against  on-line  databases 
which  they  are  allowed  to  access.  Ad  hoc  querying  is  constrained  by  AFIRMS  security  and 
control  requirements.  This  capability  is  limited  to  databases  located  at  the  functional 
area  and  the  central  location  within  a  wing.  Ad  hoc  queries  that  act  on  wing  databases 
cannot  be  initiated  from  a  MAOCOM  or  HQ  USAF.  Controls  within  the  DBMS  and  security 
software  are  used  to  limit  access  to  both  the  functional  area  and  central  databases  on  a 
user-by-user  basis. 

The  ad  hoc  query  access  is  provided  by  the  AFIRMS  executive.  The  user  has  the 
ability  to  interactively  query  the  database  via  an  "English-like"  AFIRMS  query  utility. 

The  user  doesnot  have  the  cibility  ♦o  update  any  data  while  in  this  mode.  Ad  hoc  queries 
are  limited  to  current  or  crisis  mode  data  only.  When  data  is  requested,  if  it  is  not 
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present  in  the  local  functional  area  database,  the  request  is  transmitted  to  the  central  node. 
The  request  is  then  processed  at  the  central  node  and  the  results  returned  to  the  requesting 
functional  area  for  display.  Different  data  management  software  may  be  involved  in  the 
request.  If  so,  the  syntax  translation  between  the  query  languages  embedded  within  each 
DMS/DBMS  must  be  transparent  to  the  user. 


It  is  not  anticipated  that  wing  users  require  the  ad  hoc  query  capability  as  often  as 
MAJCOM  and  HQ  USAF  users  do.  Certain  wing  users  have  the  ability  and  privilege  to 
execute  these  queries  and  create  data  under  the  jurisdiction  of  the  local  DBMS  within 
AFIRMS  system  control. 


2.3.3  What-if  Capability.  A  what-if  capability  exists  in  AFIRMS  to  enable  certain  users  to 
input  hypothetical  tasking,  resource,  or  operations  scenarios  in  order  to  better  predict  future 
readiness  capability.  The  data  is  input  into  the  local  database  through  a  highly  structured 
AFIRMS  environment.  The  what-if  capability  of  AFIRMS  directly  affects  the  amount  of  data 
redundancy  necessary  at  the  wing  and,  accordingly,  the  amount  of  physical  storage  capacity 
necessary  to  handle  it.  What-if  data  storage  needs  vary  according  to  the  level  in  the 
command  structure  and  the  functional  area's  what-if  exercise  needs.  Wings  typically  require 
less  physical  storage  for  what-if  capability  than  MA3COMs  or  HQ  USAF  do. 


2.3.4  Reporting.  Reporting  of  a  lower  site  to  a  site  higher  in  the  command  structure  is 
accommodated  by  similar  database  architectures  at  the  different  levels.  Data  formats  and 
structures  exist  at  both  sites  in  order  to  facilitate  report  transmissions.  Reports  occur  on  a 
periodic  basis  as  well  as  on  an  "as-needed"  basis.  The  data  involved  in  these  intersite  reports 
describes  the  status  of  the  wing  summary  resource(s),  base(s),  and  unit(s). 


2.3.3  Data  Redundancy.  Data  redundancy  within  the  wing  is  kept  to  a  minimum  in  order  to 
decrease  data  consistency  problems  and  extra  software  required  to  maintain  the  database. 
Sometimes,  however,  retrieval  speed  becomes  an  important  requirement  and  a  level  of 
redundancy  must  be  introduced  to  accommodate  it.  The  AFIRMS  LPP  has  demonstrated  a 
need  for  such  data  redundancy,  which  can  be  handled  by  the  minimumlocal  redundancy 
architecture.  Analysis  performed  in  the  initial  block  of  each  segment  identifies  the  data 
items  needed  most  by  different  functional  areas,  how  often  they  are  required,  and  who  is 
responsible  for  maintaining  them.  The  database  designer  must  have  this  information  in  order 
to  effect  a  design  under  the  chosen  architecture. 
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Redundancy  of  data  between  lower-  and  higher-level  sites  is  required  for  the  report 
function  between  sites.  If  data  communications  are  hindered  among  sites,  but  manual 
communications  are  available,  the  higher  sites  can  still  operate  based  on  the  last  reported 
summary  data.  This  type  of  redundancy  is  only  for  data  reported  on  a  regular  or 
as-needed  pre-packaged  basis.  Ad  hoc  querying  of  lower  sites  is  not  permitted  within 
AFIRMS. 

At  the  wing,  each  functional  area  has  locally  stored  data  it  needs  on  a  regular  basis. 
The  database  is  composed  of  real  data,  exercise  data,  and  Designed  Operational 
Capability  (DOC)  data.  The  exercise  and  DOC  data  comprise  the  what-if  data  present  at 
the  wing  level.  There  is  a  total  of  five  what-if  databases  permitted  to  be  stored  on-line, 
plus  one  database  storing  actual  current  data  for  a  total  of  six. 

The  following  shows  a  sample  breakdown  of  copies  of  AFIRMS  data  resident  at  the 
wing  level: 

1  copy  of  current  real  data 

5  copies  of  what-if  data  consisting  of 

2  copies  of  1  exercise  database  (1  beginning  copy  and  1  ending  copy) 

5  databases  depicting  results  of  Sortie  Generation  Model  runs  against  the 
DOC. 

Since  there  is  a  maximum  of  5  copies  of  what-if  databases  on-line  two  of  the  7  above 
must  reside  off-line  at  the  discretion  of  the  wing. 


2.3.6  Database  Backup,  Archiving,  and  Restoration.  Following  is  the  regular  schedule  for 
backups  of  the  AFIRMS  databases  to  off-line  media  at  the  wing: 

1)  At  the  end  of  each  working  day;  retained  for  5  working  days 

2)  At  the  end  of  each  week;  retained  for  5  weeks 

3)  At  the  end  of  each  month;  retained  for  12  months 

4)  At  the  end  of  each  year;  retained  for  5  years. 
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The  data  involved  in  the  backup  schedule  above  is  used  for  historical  purposes  also. 
Moreover,  data  can  be  backed-up  on  an  "as-needed"  basis.  An  example  of  this  occurs 
during  exercise  mode  or  crisis  situation  when  AFIRMS  is  being  used  outside  normal  usage 
periods,  for  instance,  on  a  weekend.  Normally,  the  database  is  not  automatically 
backed-up  on  the  weekend,  but  in  this  situation  backup  is  manually  initiated  as  required  by 
the  functional  area  user.  Archiving  occurs  in  the  same  manner;  it  is  initiated  manually. 
The  difference  is  that  archived  data  is  not  deleted  from  off-line  media  unless  explicitly 
requested.  For  this  reason  archiving  is  a  tool  that  is  to  be  used  sparingly  for  important 
data.  Archiving  is  initiated  as  required  by  the  functional  area  user.  Restoration  occurs  if 
data  in  the  database  or  transactions  on  the  data  have  been  lost.  Whenever  a  transaction 
occurs  in  the  local  database,  it  is  logged  to  an  on-line  journal  file  for  use  in  the  event 
restoration  is  needed.  Restoration  consists  of  reloading,  if  necessary,  the  latest  copy  of 
the  database  from  off-line  media  and  applying  the  journal  log  file  to  it. 

2.3.7  External  Interfaces.  It  is  desired,  whenever  possible,  for  AFIRMS  to  have 
direct-line  interfaces  to  other  systems'  data  that  is  useful  to  AFIRMS  on  a  regular  basis. 
There  are  circumstances,  however,  where  a  direct-line  interface  is  not  feasible  due  to 
hardware,  software,  or  security  constraints.  For  example,  as  a  classified  NATO  system, 
the  EIFEL  system  currently  operating  in  USAFE  is  prohibited,  for  security  reasons,  from 
being  physically  connected  to  classified  USAF  ADP  systems.  If  it  is  subsequently  deemed 
necessary  to  have  an  interface  between  AFIRMS  and  EIFEL  it  must  be  by  an  "airgap,"  i.e., 
hardcopy,  magnetic  tape,  or  floppy  disk.  Airgap  interfaces  occur  by  [periodically  copying 
to  tape,  or  floppy  disk,  the  necessary  data  from  those  systems  and  loading  it  to  AFIRMS. 
Data  updated  via  an  interface  consists  of  only  that  data  which  has  changed  since  the 
previous  data  transfer  from  the  external  system.  For  example,  in  the  AFIRMS/Air  Force 
Operations  Resource  Management  System  (AFORMS)  interface,  only  those  events  that 
were  performed  by  the  aircrew  member  through  the  current  date  since  the  last  interface 
occurred  constitute  a  transaction  in  the  AFIRMS  database. 

2.3.8  Normalization  and  Data  Models.  Normalization  is  a  technique  of  relating 
functionally  dependent  data  for  ease  of  understanding  and  operationally  maintaining  data 
integrity  by  reducing  update  anomalies.  Normalization  is  a  good  starting  point  for  any 
database  design  because,  although  normalization  adapts  most  readily  to  the  relational 
data  model,  it  characterizes  relationships  between  data  to  the  extent  where  minimal 


changes  are  necessary  to  switch  to  a  network,  hierarchical,  or  other  data  model.  This 
makes  for  ease  of  adaptability  between  wings  during  the  Analysis  Phase  of  their  block 
implementations. 


Each  of  the  logical  data  models  mentioned  above  has  inherent  advantages  and 
disadvantages.  Network  logical  data  models  have  the  speed  and  flexibility  to  work  in 
almost  any  application  but  are  very  difficult  to  implement  effectively  and  are  not  at  all 
flexible  if  the  need  for  reorganization  arises.  Hierarchical  logical  data  models  are  usually 
a  good  choice  for  hierarchically  structured  applications,  but  they  are  not  very  flexible. 
While  AFIRMS  is  hierarchical  in  organization,  the  variability  of  data  requirements  among 
functional  areas  requires  significant  data  structure  flexibility.  This  is  particularly  true 
when  the  evolutionary  nature  of  AFIRMS'  implementation  is  considered.  Relational 
logical  data  models  are  the  easiest  to  implement  and  are  very  flexible.  However,  they 
lack  the  access  speed  of  some  of  the  other  models.  During  the  AFIRMS  LPP,  it  became 
apparent  that  flexibility  and  relative  ease  of  implementation  weigh  heavily  in  the  AFIRMS 
development  environment.  In  this  sense,  the  use  of  a  relational  DBMS  was  of  great  value. 
Other  logical  data  models  such  as  inverted  files  have  greater  speed  than  relational  models 
but  also  possess  limited  flexibility. 


2.3.9  DBMS  Characteristics.  This  section  lists  the  desired  characteristics  of  a  DBMS  for 
AFIRMS  in  order  of  highest  to  lowest  priority.  Some  characteristics  will  differ  in  degree 
of  relevance  between  wings  and  should  be  re-prioritized  accordingly  during  the  Analysis 
Phase  of  the  first  blocks  of  the  operational  systems.  The  DBMS  should  support  or  provide: 


a.  Highest. 

(1)  Access  by  multiple  users  from  interactive  and  batch  processes  for  both 
update  and  retrieval  of  information. 

(2)  Application  program  data  independent  of  the  physically  stored  data 
structures. 

(3)  A  database  creation  facility  for  the  initialization  and  loading  of  the 
database. 


(4)  Interaction  with  higher-order  languages  (HOLs). 

(5)  An  English-like  query  language  to  process  data  in  any  file  using  the  DBMS. 


I 

(6)  Creation  of  the  query  must  be  supported  by  the  dictionary  facility  to 
inform  the  user  of  the  permitted  view  and  to  permit  selection  of  the  data 
elements  to  be  reported. 

(7)  A  query  language  that  provides  interactive  editing  of  syntax,  terms,  and 

I  element  names. 

(8)  A  query  language  that  supports  the  use  of  Boolean  operators. 

(9)  Directing  the  results  of  a  query  to  a  file  that  can  be  used  by  other 

I  applications  or  support  software. 

(10)  The  ability  to  optionally  round  or  truncate  numerical  fields. 

(1 1)  Adding,  deleting,  or  updating  a  record  in  either  batch  or  on-line  mode. 

[  (12)  Extending  DBMS  functions  without  changing  or  recompiling  existing 

'  processes.  Specifically,  the  ability  to  add  functions  to  the  DBMS  without 

affecting  the  user  language  interface.  The  addition  of  these  functions  is 
transparent  to  any  existing  routines  that  have  been  written  in  the  DBMS 
user  language  or  any  other  languages. 

(13)  A  database  dictionary  capable  of: 

(a)  Describing  databases,  data  elements,  authorized  users,  logical  user 
views,  and  specifying  user  permissions  (read/write/update). 

(b)  Generating  data  definitions. 

(c)  Restricting  access  to  the  database  dictionary  according  to  security 
requirements. 

(d)  Defining  multiple  occurrences  of  data. 

(e)  Modifying  the  database  in  size,  relationships,  access  methods,  or 
fields  per  record  without  requiring  modification  of  application 
programs  for  which  processing  logic  does  not  change. 

b.  Medium. 


(1)  A  logical  comparison  capability  during  search  and  update  functions. 

(2)  Searches  for  a  record  number  or  a  field  (using  alphanumeric,  special 
characters,  or  wildcard  notation). 

(3)  A  built-in  HELP  capability  accessible  at  any  level. 

(4)  A  query  system  with  the  ability  to  perform  tabulations  and  arithmetic 
functions,  or  interface  with  a  statistical  package. 

(5)  Development  of  a  query  by  menus,  prompting,  and/or  HELP  facilities. 

(6)  The  ability  of  one  query  to  retrieve  data  from  multiple  files  with  a 
database. 
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(7)  A  query  language  with  the  ability  to  logically  manipulate  data. 

(8)  A  query  language  with  the  ability  to  perform  grouping  operations  for 
totals,  counts,  or  specified  calculated  fields. 

(9)  The  results  of  a  query  displayed  on  a  screen  to  be  directed  to  a  file  for 
printing  later. 

(10)  The  ability  to  specify  up  to  five  control  break  levels  (subtotals  for  up  to 
ten  columns). 

(11)  The  ability  of  a  user  to  store  a  query  and  allow  the  user  or  other  users, 
subject  to  security  constraints,  to  reuse  the  query.  Stored  queries  must 
be  able  to  be  reused  either  in  their  entirety  or  with  the  addition  or 
modification  of  specific  parameters  by  the  current  user,  and  must  be 
indexed  or  cataloged  to  support  menu-driven  retrieval  of  stored  queries. 

(12)  Recovery  and  restart  capabilities  for  the  DBMS  files. 

(13)  Utilities  which  permit  database  reorganization,  dump  and  restore,  and 
usage  statistics. 

(14)  Interfaces  with  a  report  writer. 

(15)  The  automatic  return  of  disposed  space  (as  in  the  case  of  a  deletion)  to 
the  system  or  reallocate  space  itself.  This  avoids  excessive  compressing 
or  reorganizing  of  data  in  order  to  recover  disposed  spaces  (holes). 

Lowest. 

(1)  Unlimited  number  of  records  per  file  within  available  disk  space. 

(2)  Access  of  last  record,  previous  record,  and  next  record. 

(3)  File  searches  containing  at  least  six  search  criteria. 

(4)  The  ability  of  a  query  language  to  decode  fields. 

(5)  A  query  language  which  automatically  aligns  decimal  points  or  other 
punctuation  for  fields. 

(6)  Data  integrity  that  prevents  simultaneous  updates  and  deadlocks,  and 
maintains  the  logical  and  physical  structure  of  the  database. 

(7)  A  capability  under  exclusive  control  of  the  Database  Administrator  to 
repair  a  database  record  that  is  unreadable. 

(8)  The  ability  of  the  host  language  interface  to  accept  asynchronous  requests 
as  well  as  request  cancellations. 


2.4  Security.  The  most  critical  aspect  of  security  protection  for  the  operational  AFIRMS 
is  at  the  Wing  level  where  the  AFIRMS  ADPS  will  be  operating  in  a  Controlled  Security 
Mode  at  the  secret  level  with  a  mixture  of  classified  and  unclassified  terminals  and  users. 
With  this  security  environment,  it  is  imperative  that,  in  compliance  with  AFR  205-16, 
database  access  controls  be  implemented  based  on  clearance  levels  of  users  and  terminals 
and  users'  need-to-know.  The  database  security  protection  features  for  the  operational 
AFIRMS  ADPS  at  Wing  sites  must  include  at  least  the  following: 

a.  Terminal  and  user  profiles  indicating  user  and  terminal  clearance  level,  access 
privileges,  and  user/terminal  permissions  (read/write/update). 

b.  The  ability  to  assign  security  classification  levels  to  files  and/or  data  elements. 

c.  The  ability  to  restrict  database  access  based  on  user/terminal  clearance  level 
and  need-to-know. 

d.  The  ability  to  restrict  the  number  of  invalid  access  attempts  to  the  system 
and/or  database. 

e.  The  ability  to  create  and  maintain  an  audit  trail  to  include: 

1.  Record  of  accesses  made  to  files;  how,  and  from  where  these  accesses 
were  initiated. 

2.  Identity  of  user  and  terminal  that  initiated  access. 

3.  Record  of  all  unauthorized  access  attempts. 
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SECTION  3.  DATA  DEFINITIONS 


3.1  Data  Files. 

3. 1. 1  General  Description  of  Data  Files.  Appendices  A  and  B  of  this  document  list 
general  wing  data  requirements  for  the  central  database  and  each  functional  area. 


3. 1. 1.1  Entity  Class  Characteristics.  The  column  designated  appearance  number  in 
Appendices  A  and  B  has  embedded  within  it  the  number  of  the  entity  class  to  which  it 
belongs.  Section  3.2  of  the  Data  Requirements  Document  completely  describes  the 
characteristics  of  each  entity  class  existing  at  the  wing.  A  listing  of  entity  classes  by 
functional  area  is  developed  in  the  analysis  phase  of  each  segment. 


3.1.2  Physical  Characteristics  of  Data  Files. 

a.  File  Contents  and  Format.  All  contents  of  AFIRMS  database  files  are  under  the 
control  of  the  DBMS  or  data  management  system  (DMS)  resident  on  the  local 
computers.  They  are  in  a  format  recognized  by  the  DBMS/DMS  and  are 
accessed  via  the  DBMS/DMS. 

b.  Primary  and  Secondary  Storage  Media.  All  AFIRMS  database  files  reside  on 
disk  storage  for  on-line  access  and  magnetic  tape  or  floppy  disk  media  for 
archiving  and  backup. 

c.  Form  of  the  Contents.  The  form  of  the  contents  of  all  AFIRMS  database  files 
is  binary. 


3.1.3  Logical  Characteristics  of  Data  Files.  Appendix  A  lists  and  describes  all 
appearances  of  data  in  the  Wing  central  database  as  referenced  in  the  DRD.  Appendix  B 
lists  and  describes  all  appearances  of  data  by  functional  area  at  the  wing. 


3. 1.3.1  Appearance  Class  Characteristics.  Each  appearance  class  referenced  in  Appendix 
A  and  B  is  described  completely  in  Section  3.2  of  the  Data  Requirements  Document. 
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3.2  Tables.  Internal  tables  used  to  manage  or  describe  AFIRMS  data  files  are  defined 
during  the  analysis  phase  of  each  segment. 

3.3  Items.  Items  resident  in  the  tables  described  in  Section  3.2  are  defined  during  the 
analysis  phase  of  each  segment. 

3.4  Records  and  Entries.  Records  or  entries  appearing  in  AFIRMS  data  files  are  defined 
during  the  analysis  phase  of  each  segment. 


SECTION  4.  INTEGRATED  DATABASE 


The  AFIRMS  database  can  be  divided  into  three  different  types;  HQ  USAF,  HQ  USAFE, 
and  WING.  Data  is  duplicated,  to  some  degree,  between  levels  by  the  reporting  function. 
In  this  sense,  then,  the  AFIRMS  database  is  not  truly  integrated  because  of  data 
redundancy  existing  at  the  different  levels. 

At  the  wing  level,  there  exists  a  central  database  connected  to  multiple  functional 
areas.  Each  functional  area  has,  physically  resident  on  its  hardware,  a  database  which 
duplicates  all  or  part  of  the  central  database. 

AFIRMS  is  integrated  in  the  sense  that  duplication  of  manual  data  inputs  is 
minimized  by  the  fact  that  AFIRMS  interfaces  with  other  ADP  systems  to  access 
necessary  data.  Data  inputs  are  "integrated,”  since  they  are  collected  from  multiple 
systems  without  need  for  redundant  AFIRMS  user  input.  These  inputs  are  stored  for  use 
by  AFIRMS  processes.  This  means  that  the  AFIRMS  central  database  is  not  integrated 
within  the  wing  environment  since  the  same  data  is  stored  and  used  at  both  the  central 
and  functional  areas.  However,  the  AFIRMS  central  database  houses  data  from  different 
functional  areas  non-redundantly  and,  therefore,  is  itself  integrated  because  multiple 
functional  users  are  accessing  the  same  data.  Special  problems  such  as  deployability, 
availability,  and  retrieval  speed  require  each  functional  area  to  have  data  that  it  routinely 
needs  resident  on  its  own  hardware.  From  this  perspective,  a  central  database  with 
redundant  data  at  the  functional  areas  is  not,  strictly  speaking,  an  integrated  database, 
when  considered  together  even  though  each  (considered  individually)  is  integrated. 

When  one  or  more  users  in  a  subfunctional  area  are  accessing  the  same  database,  then 

that  database  is  also  integrated  because  the  AFIRMS  architecture  prohibits  redundancy 

\ 

within  that  functional  area.  This  does  not  preclude  the  possibility  that  the  same  data  is 
duplicated  at  the  central  database  or  another  functional  area. 

To  summarize,  AFIRMS  collects  data  both  as  AFIRMS  inputs  and  via  electronic 
interfaces  with  other  systems.  AFIRMS  stores  this  data  for  use  by  many  different 
functional  users  in  a  collection  of  decentralized  databases,  each  one  of  which  (taken 
alf''^e)  is  an  integrated  database.  However,  the  data  is  redundant  within  and  between 
AFIRMS  sites  as  well  as  between  other  Air  Force  systems.  Therefore,  AFIRMS,  as  a 
system,  does  not  operate  on  a  truly  integrated  database. 


APPENDIX  A/CHGl.  WING  CENTRAL  DATABASE  STORAGE  REQUIREMENTS 


APPEARANCB 

NOHBBR 


APPBARANCB  NAMB 


UNIT  MISSION 

UNIT  OPBRATIONS  IISIRIPIBR 
UNIT  SHORT  NAMB 

RBSOURCB  TYPB  (3  MIB  »  5  A/CRW  +  30  MUNITIOM  «  POBL) 

RBSOURCB  UNITS  OP  MBASURB 
RBSOURCB  TYPB  NBBBD  POR  A  TASK 
TASK  TYPB  SBT  IIBNTIP3R 
RBSOURCB  PRIORITY 

STANSARS  QUANTITY  OP  RBSOURCB  RBQUIRBD 

TASK  TYPB 

TASK  PRIORITY 

TASK  TYPB  BZBCVriON  TIMB 

TASK  PBRIOD  PROM  DAY  (60  DAYS) 

TASK  PniOD  TO  DAY 
AIRCRAPT  UNIT  NAMB 
AIRCRAPT  SBRIAL  NUMBBI 
AIRCRAPT  MDS 

AIRCRAPT  OPBRATIONAL  STATUS 
AIRCRAPT  OPBRATIONAL  STATUS  RBIARXS 
AIRCRAPT  LOCATION 
AIRCRAPT  BTIC 

AIRCRAPT  TANK  CONPIOURATION 

AIRCRAPT  STATION  STATUS 

AIRCRAPT  PRESBLBCT  INDICATOR 

AIRCRAPT  OBNBRATION  PACTCR 

AIRCRAPT  TAIL  NUMBER 

AIRMAN  U3T  NAMB  (72  MBOBRS  x  3  SQDHS) 

AinUN  UNIT  NAMB 
AIRMAN  AVAILABIUTY  STATUS 
AIRMAN  CRBN  DAY  START 
AIRMAN  STATUS  RWARKS 
AIRMAN  RANK 
AIRMAN  BTR 

AIRMAN  CRBH  POSITION 
AIRMAN  DOTY  STATUS 
AIRMAN  ATTACHBD  UNH  NAMB 
AIRMAN  ASSIORMBHT  TYPB 
AiniAN  BXPBCTBD  NR  DATB 
AIRMAN  DOTY  STATUS  QUAUPIBR 
UNn  NAMB  (MNINO  RBSOURCB 
RBSOURCB  OBSIQNATOR 

RBSOURCB  AOTHORIZBD  AMOUm  (30  MUNITION  *  4  PUBL  *  12  ACRPT  *  8  ACRV) 

RBSOURCB  SBT  IDBmiPIBR 

RBSOURCB  LAST  INVBNTORI  DATB 

RBSOURCB  ASSIONBD  AMOUNT 

RBSOURCB  CURRBNT  AMOUIR 

RBSOURCB  CURRBNT  OPP  BA3B  AMOUNT 

BASB  NAMB  -  UNIT'S  RBSOURCB  LOCATION  (5  VINO  LOCATIONS) 

RBSOURCB  POSSBSSBD  TOTAL 
RBSOURCB  ROLL-UP  DTO 
RBSOURCB  TRANSNH  DTO 
AIRCRBHS  NR 


3IZB  QUANTITY 


APPENDIX  A/CHGl.  WING  CENTRAL  DATABASE  STORAGE  REQUIREMENTS  (Cont.) 


APPEARANCB 


HUHBER 

APPBARANCB  NAHB 

SIZE 

QUARITY 

SIZE 

13Q 

AIRCRAPT  HC 

4 

2 

48 

13R 

H  BXPENOBO  SUPPLY 

4 

30 

720 

133 

RBSOURCB  CURRBMT  BUILT  AMOUNT 

4 

30 

720 

13T 

H  OPP  BABB  AMOUNT 

4 

30 

720 

13U 

RBOURCB  RB1ARKS1 

30 

30 

5400 

13V 

RBSOURCB  SUPPLY  CRITICAL  LEVBL 

4 

30 

720 

13W 

RESOURCE  TOTAL  CURRENTLY  AVAIUBLB 

4 

30 

720 

13X 

RESOURCE  SUPPLY  BAYS  RBUINIMO 

4 

30 

720 

13t 

RBSOURCB  DAILY  BXPENOITURB  RATE 

4 

30 

720 

13Z 

RBSOURCB  SUPPLY  DAYS  UNTIL  CRITICAL 

4 

30 

720 

15C 

MISSION  NUMBER  (50  z  5  DAYS  IN  3CHE0ULB) 

7 

250 

10500 

150 

PRIMARY  MISSION  TYPB  ASSIONBD 

5 

5 

150 

15B 

MISSION  UNIT  NAME 

10 

3 

180 

15P 

MISSION  HUMBER  OP  AIRCRAPT 

4 

250 

6000 

150 

MISSION  START  TIME  OVER  TAROBT 

5 

250 

7500 

15H 

MISSION  STOP  TIME  OVD  TAROBT 

5 

250 

7500 

15L 

SUPPORT  MISSION  NUMBER 

7 

250 

10500 

ISM 

MISSION  TAROBT  DESCRIPTION 

15 

250 

22500 

150 

MISSION  PRIORITY 

4 

250 

6000 

15U 

MISSION  TURN  BACK  PUO 

1 

250 

1500 

15V 

MISSION  REMARKS 

60 

250 

90000 

15W 

MISSION  TASKED  MUNITION  CODB 

6 

250 

9000 

20A 

UNIT  NAHB  OP  SUPPLY  (MNBR  AT  THIS  LOCATION 

10 

1 

60 

SOB 

RBSOURCB  TYPE  OP  SUPPLY  AT  THIS  LOCATION 

20 

54 

6480 

20C 

SUPPLY  LOCATION  TYPB 

15 

2 

180 

200 

SUPPLY  LOCATION  NUMBER  (12  PUBL  TANK  ♦  80  ACRPT  SHELTER) 

12 

92 

6624 

20B 

SUPPLY  LOCATION  RESOURCE  CAPACITY  (12  PUBL  LOCATIONS) 

4 

12 

288 

20P 

T  SUPPLY  LOCATION  RESOURCE  INVENTORY  (12  PUBL  LOCATIONS) 

4 

12 

288 

2oa 

SUPPLY  LOCATION  RBSOURCB  INVENTORY  DATE  (12  PUBL  LOCATIONS) 

7 

12 

504 

20H 

RESOURCE  SUPPLY  IDBNTIPIBR 

23 

1 

138 

20J 

STORAGE  CONTAINER  SERVICEABILITY  (12  PUBL  LOCATIONS) 

15 

12 

1080 

20K 

STORAGE  CONTAINBR  ETIC  (12  PUBL  LOCATIONS) 

12 

12 

864 

20L 

STORAGE  CONTAINER  RBURKS  (12  PUEL  LOCATIONS) 

15 

12 

1080 

39A 

OWNINO  RESOURCE  DESIGNATOR 

20 

25 

3000 

39B 

SUBORDINATE  RESOURCE  DESIGNATOR 

20 

54 

6480 

50A 

SORTIE  SEQUENCE  NUMBER  (1  WEEK'S  WORTH) 

4 

375 

9000 

500 

SORTIE  ASSIONBD  TAKB-OPP  TIME 

5 

375 

11250 

50B 

SORTIE  EXPECTED  UND  TIME 

5 

375 

11250 

50P 

SORTIE  AIRCREW  SHOW  TINE 

5 

375 

11250 

50Q 

SORTIE  AIRCREW  CCHPLBTION  TIME 

5 

375 

11250 

503 

SORTIE  MISSION  AIRCRAPT  HD6 

7 

4 

168 

53A 

BASE  NAHB 

15 

5 

450 

530 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53B 

BASE  NBC  STATUS 

3 

5 

90 

53P 

BASE  RIC 

11 

5 

330 

530 

BASE  STATUS  RB1ARKS 

140 

5 

4200 

53H 

BASE  STATUS  AS  OP  DTG 

10 

5 

300 

5AA 

ORDER  IIBRIPIBR 

23 

4 

552 

54B 

0RDB1  DATE 

7 

1 

42 

540 

ORDER  CHANGE  NUMBER 

4 

4 

96 

54K 

ORDER  CUSSIPICATION 

21 

1 

126 

54Q 

NUMBER  OP  DAYS  TO  RUN  SOM  MODEL 

4 

10 

240 

32091 


SOFfeCH 


APPENDIX  A/CHGl.  WING  CENTRAL  DATABASE  STORAGE  REQUIREMENTS  (Cont.) 


APPBARANCE 

NUtBBR 


APPBARANCB  NAME 


QUANTITY 


SORTIE  OBHERATION  HOIBL  RUM  RBURKS 

TASKED  OMIT  NAME 

UNIT  ORDER  IDBHTIPICATION 

BASE  NAME  -  UNIT  mPLOYMENr  LOCATION 

UNIT  EHPLOYMEin  DAY 

T  UNIT  DAILY  SORTIE  TASK 

T  UNIT  DAILY  INTEGRATED  SORTIE  CAPABILITY 

UNIT  PUNNED  SORTIE  DURATION 

UNIT  SHIFT  DURATION 

UNIT  FLY  DAY  NUMBER 

T  UNIT  DAILY  RESOURCE  QUAIRITY  TASKED 

UNIT  NAME 

UNIT  TURN  TIME  FOR  ORDER 

PBtlOD  START  DAI  FOR  UNIT'S  PIECE  OP  0RD« 

PERIOD  END  DAY  FOR  UNIT'S  PIECE  OP  ORDER 
UNIT  HAINT  ATIRIT  RATE  FOR  ORDBI 
NISSIOR  TYPE 

UNIT  AIRCRAFT  REPAIR  RATE  FOR  ORDH 

UNIT  MIN  TIME  BBIWEEN  TAKEOFFS 

UNIT  COMBAT  ATTRIT  RATE  FOR  ORDER 

SORTIES  PER  DAT 

MISSION  PRIORITY 

PRIMARY  RESOURCE  TYPE 

AIRMAN  LAST  NAME  •  POSSESSOR  OP  SKILL 

SKIU  IDENTIFIER  .  SKIU  POSSESSED 

SKIU  LEVEL 

SKIU  IDEMTIFIBR  .  RESOURCE 
ORDER  IDENTIFIER 
TASK  PERIOD  START  DAY 
TASK  PERIOD  END  DAI 

RESOURCE  TYPE  REQUIRED  FOR  TOTAL  ORDER  (3  ACRFT  +  1  ACfM  +  34  RESOURCE) 
RESOURCE  QUANIITT  REQUIRED  FOR  TOTAL  ORDER 
SORTIE  AIRCRAFT  RATE  (60  DAT  z  3  NDB) 

SORTIE  DURATION  (60  DAY  z  5  MISSION) 

UNIT  NAME  -  FOR  TASKED  UNIT 
RESOURCE  TYPE  SUPPORTIHO  UNIT  TASK 

TJUNIT  DAILY  RESOURCE  SORTIE  CAPABILITT  (38  RESOURCES  z  60  DAYS) 

T  UNIT  DAILY  RESOURCE  QUANTITY  CAPABLE 
UNIT  RESOURCE  AMOUNT  TASKED 
TASKED  UNn  NAME 

RESOURCE  TYPE  IN  UNIT'S  TASKING  PIECE 

RESOURCE  QUANTITY  REQUIRED  FOR  TASK  TYPE  IN  UNIT'S  PIECE  OP  ORD0  (5  z  38  RES) 
FLY  DAY  WAVE 

DAILY  TOTAL  SORTIE  RESOURCES  PRODUCED 
QUANTITY  OF  TYPE  IN  STATUS 
RESOURCE  TYPE  OF  UNIT'S  SUPPLY  IN  STATUS 
FLY  DAY  START 

SHIFT  PERCENT  FORMED  AIRCREW 
FLY  DAY  DURATION 
SHIFT  START  TIME 
REQUISITION  RESOURCE  TYPE 
DUE-OUT  REQUISITION  NUMBER 


SSSSiS 


APPENDIX  A/CHGl.  WING  CENTRAL  DATABASE  STORAGE  REQUIREMENTS  (Cont.) 


APPBARAHCB  TOTAL 


miMBBR 

APPEARANCE  NAME 

SIZE 

QUAtreiTY 

SIZE 

92C 

DUB-IN  RBQUiamON  NlflBER 

U 

20 

1680 

921) 

HICAP  START  DATE 

11 

20 

1320 

92B 

NWIBER  OP  HICAP  DAYS 

A 

20 

A80 

92P 

REQUISITION  CAUSE  CODE 

1 

20 

120 

920 

REQUISITION  ROUTE  ID 

3 

20 

360 

92H 

REQUISITION  RBIARKS 

30 

20 

3600 

92J 

REQUISITION  UNIT  NAME 

10 

20 

1200 

96B 

RESOURCE  NAME 

23 

7 

966 

96C 

RESOURCE  STATUS 

3 

7 

126 

96D 

RESOURCE  STIC 

11 

7 

A62 

96B 

RESOURCE  RBtARKS 

A 

0 

0 

TOTAL  DATA 

SIZE  = 

1109A72 

TOTAL  OPERATIONAL  DATABASE 

SIZE  : 

2951 195 

I 


32091 


A -9 


APPENDIX  B/CHGl.  WING  FUNCTIONAL  AREA  DATABASE  STORAGE  REQUIREMENTS 

AIRCRAFT  MAINTENANCE  UNITS  (AMU) 


APPBARAHCB 

NUMBER 


APPEARANCE  NAME 


SIZE  QUANTITY 


AIRCRAFT  UNIT  NAME 

10 

AIRCRAFT  SERIAL  NUMBER 

A 

AIRCRAFT  MBS 

7 

AIRCRAFT  OPERATIONAL  STATUS 

8 

AIRCRAFT  OPERATIONAL  STATUS  RSURKS 

80 

AIRCRAFT  LOCATION 

4 

AIRCRAFT  ETIC 

5 

AIRCRAFT  TANK  CONFIQURATION 

1 

AIRCRAFT  STATION  STATUS 

3 

AIRCRAFT  PRESELECT  INDICATOR 

4 

AIRCRAFT  OENERATION  FACTOR 

4 

AIRCRAFT  TAIL  NUMBER 

5 

RESOURCE  AUTHORIZED  AHOUHT 

4 

RESOURCE  ASSIGNED  AMOUNT 

4 

RESOURCE  CURRENT  AMOUNT 

4 

RESOURCE  CURRENT  OFF  BASE  AMOUNT 

4 

RESOURCE  POSSESSED  TOTAL 

4 

BASE  NAME 

15 

BASE  OPERATIONAL  STATUS 

3 

BASE  NBC  STATUS 

3 

BASE  STIC 

11 

BASE  STATUS  RB1ARKS 

140 

BASE  STATUS  AS  OF  DTO 

10 

QUANTITY  OF  TYPE  IN  STATUS 

4 

RESOURCE  NAME 

23 

RESOURCE  STATUS 

3 

RESOURCE  STIC 

11 

RESOURCE  RBIARKS 

4 

TOTAL  DATA 

SIZE 

TOTAL  OPERATIONAL  DATABASE 

SIZE 

FUELS  CONTROL 


APPEARANCB  TOTAL 


NUnSER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

ONIT  MISSION 

3 

5 

90 

IP 

UNIT  SHORT  NAME 

8 

4 

192 

5A 

RESOURCE  TYPE 

20 

42 

5040 

5E 

RBSOORCB  WITS  OP  MEASURE 

8 

5 

240 

11A 

AIRCRAFT  WIT  NAME 

10 

4 

240 

11B 

AIRCRAFT  SniAL  NUMBER 

4 

80 

1920 

11C 

AIRCRAFT  Mm 

7 

4 

168 

11E 

AIRCRAFT  OPERATIONAL  STATUS 

8 

7 

336 

IIP 

AIRCRAFT  OPERATIONAL  STATUS  RBURKS 

80 

80 

38400 

no 

AIRCRAFT  LOCATION 

4 

80 

1920 

IIH 

AIRCRAFT  ETIC 

5 

80 

2400 

UK 

AIRCRAFT  TANK  CONFIOURATION 

1 

80 

480 

111 

AIRCRAFT  STATION  STATUS 

3 

4 

72 

11(1 

AIRCRAFT  PRESELECT  INDICATOR 

4 

80 

1920 

1 1N 

AIRCRAFT  OBRERATION  FACTOR 

4 

80 

1920 

IIP 

AIRCRAFT  TAIL  NUMBER 

5 

80 

2400 

13A 

WIT  NAME  (MNINO  RESOURCE 

10 

1 

60 

13B 

RESOWCE  DESIGNATOR 

20 

54 

6480 

13C 

RESOURCE  AlffHORIZEO  AHOUm 

4 

54 

1296 

13D 

RESOWCE  SET  IDBIRIFIER 

23 

1 

138 

130 

RESOURCE  ASSIOHED  AMOUIR 

4 

54 

1296 

13H 

RESOWCE  CWREirr  AMOUNT  i 

4 

54 

1296 

131 

RESOURCE  CURRENT  OFF  BASE  AMOUNT 

4 

54 

1296 

iy 

BASE  NAME  •  UNIT'S  RESOWCE  LOCATION 

15 

5 

450 

13N 

RESOURCE  POSSESSED  TOTAL 

4 

54 

1296 

13N 

RESOWCE  ROU-UP  DTG 

13 

3 

234 

130 

RESOURCE  TRANSMIT  DTG 

13 

3 

234 

13P 

AIRCRBHS  NR 

4 

2 

48 

13Q 

AIRCRAFT  IK 

4 

2 

48 

20A 

WIT  NAME  OF  SUPPLY  OWNER  AT  THIS  lOCATION 

10 

1 

60 

2QB 

RESOURCE  TYPE  OF  SUPPLY  AT  THIS  LOCATION 

20 

54 

6480 

20C 

SUPPLY  LOCATION  TYPE 

15 

2 

180 

20D 

SUPPLY  LOCATION  NUMBER 

12 

92 

6624 

20E 

SUPPLY  LOCATION  RESOWCE  CAPACITY 

4 

12 

288 

20P 

T  SUPPLY  LOCATION  RESOURCE  INVENTWY 

4 

12 

288 

200 

SUPPLY  LOCATION  RESOWCE  INVENTORY  DATE 

7 

12 

504 

20J 

STORAOB  CONTAINER  SERVICEABILITY 

15 

12 

1080 

20K 

STORAGE  CONTAINBR  ETIC 

12 

12 

864 

20L 

STORAGE  CONTAINER  RB1ARKS 

15 

12 

1080 

39A 

OWNING  RESOWCE  DESIGNATOR 

20 

25 

3000 

39B 

SUBORDINATE  RESOURCE  DESIGNATOR 

20 

54 

6480 

53A 

BASE  NAME 

15 

5 

450 

53D 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53B 

BASS  NBC  STATUS 

3 

5 

90 

53P 

BASE  STIC 

11 

5 

330 

530 

BASE  STATUS  RSIARKS 

140 

5 

4200 

53H 

BASE  STATUS  AS  OF  DTG 

10 

5 

300 

5<A 

ORDER  IDENTIFIER 

23 

1 

138 

54B 

ORDER  DATE 

7 

1 

42 

540 

ORDER  CHANGE  NUMBER 

4 

1 

24 

54K 

ORDER  CUSSIFICATION 

21 

1 

126 

56B 

BASE  NAME  -  UNIT  BlPLOYHEm  LOCATION 

15 

1 

90 

32101 


B-2 


FUELS  CONTROL  (Continued) 


APPEARANCB 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

56P 

UNIT  EMPLOYMENT  DAY 

5 

1 

30 

73A 

UNIT  NAME  -  POR  TASKED  UNIT 

10 

1 

60 

73C 

RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

4 

38 

912 

73D 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY 

4 

2280 

54720 

88C 

QUANTITY  OP  TYPE  IN  STATUS 

4 

54 

1296 

92J 

REQUISITION  UNIT  NAME 

10 

20 

1200 

96B 

RESOURCE  NAME 

23 

7 

966 

96C 

RESOURCE  STATUS 

3 

7 

126 

96D 

RESOURCE  STIC 

11 

7 

462 

96B 

RESOURCE  RBURKS 

4 

0 

0 

TOTAL  DATA 

SIZE  : 

164490 

TOTAL  OPERATIONAL  DATABASE  SIZE  ^ 

519788 

32101 


MAINTENANCE  CONTROL  OR  JOB  CONTROL  (MOC) 


APPBARAMCE  TOTAL 


number 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

11A 

AIRCRAFT  UNIT  NAME 

10 

4 

240 

11B 

AIRCRAFT  SERIAL  NUMBER 

4 

80 

1920 

lie 

AIRCRAFT  MBS 

7 

4 

168 

11E 

AIRCRAFT  OPERATIONAL  STATUS 

8 

7 

336 

11? 

AIRCRAFT  OPERATIONAL  STATUS  RBttRKS 

80 

80 

38400 

110 

AIRCRAFT  LOCATION 

4 

80 

1920 

11H 

AIRCRAFT  Erie 

5 

80 

2400 

UK 

AIRCRAFT  TANK  CONFICURATION 

1 

80 

480 

11L 

AIRCRAFT  STATION  STATUS 

3 

4 

72 

11H 

AIRCRAFT  PRESELECT  INDICATOR 

4 

80 

1920 

11H 

AIRCRAFT  OENERATION  FACTOR 

4 

80 

1920 

IIP 

AIRCRAFT  TAIL  NUMBER 

5 

80 

2400 

13c 

RESOURCE  AUTHORIZED  AMOUNT 

4 

54 

1296 

13G 

RESOURCE  ASSIGNED  AMOIMT 

4 

54 

1296 

13H 

RESOURCE  CURRENT  AHOONI 

4 

54 

1296 

131 

RESOURCE  CURREVr  OFF  BASE  AMOUNT 

4 

54 

1296 

13M 

RESOURCE  POSSESSED  TOTAL 

4 

54 

1296 

15c 

MISSION  NUMBS) 

7 

250 

10500 

15D 

PRIMARY  MISSION  TYPE  ASSIGNED 

5 

5 

150 

15E 

MISSION  UNIT  NAME 

10 

3 

180 

15P 

MISSION  NUMBER  OF  AIRCRAFT 

4 

250 

6000 

150 

MISSION  START  TIME  OVER  TARGET 

5 

250 

7500 

15H 

MISSION  STOP  TIME  OVER  TARGET 

5 

250 

7500 

15L 

SUPPORT  MISSION  NUMBER 

7 

250 

10500 

15N 

MISSION  TARGET  DESCRIPTION 

15 

250 

22500 

150 

MISSION  PRIORITY 

4 

250 

6000 

150 

MISSION  PRIORin 

4 

0 

0 

15U 

MISSION  TURN  BACK  FUG 

1 

250 

1500 

15V 

MISSION  RBURKS 

60 

250 

90000 

15W 

MISSION  TASKED  MUNITION  CODE 

6 

250 

9000 

53A 

BASE  NAME 

15 

5 

450 

53D 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53E 

BASE  NBC  STATUS 

3 

5 

90 

53P 

BASE  ETIC 

11 

5 

330 

530 

BASE  STATUS  RB1ARKS 

140 

5 

4200 

53H 

BASE  STATUS  AS  OF  UTG 

10 

5 

300 

5AA 

ORDER  IDENTIFIER 

23 

1 

138 

54E 

ORDER  DATE 

7 

1 

42 

540 

ORDER  CHANGE  NUMBER 

4 

1 

24 

54K 

ORDER  CUSSIFICATION 

21 

1 

126 

56A 

TASKED  UNn  NAME 

10 

1 

60 

56L 

UNIT  FLY  DAY  NUMBER 

4 

60 

1440 

59B 

UNIT  NAME 

7 

1 

42 

59c 

UNIT  TURN  TIME  FOR  ORDER 

4 

20 

480 

59D 

PB)IOD  START  DAY  FOR  UNIT'S  PIECE  OF  ORDER 

4 

20 

480 

59E 

PERIOD  END  DAY  FOR  UNIT'S  PIECE  OF  ORDER 

4 

20 

480 

59P 

UNIT  MAINT  ATTRIT  RATE  FOR  ORDER 

4 

20 

480 

590 

MISSION  TYPE 

5 

5 

150 

59H 

UNIT  AIRCRAFT  REPAIR  RATE  FOR  ORDER 

4 

20 

480 

591 

UNIT  MIN  TIME  BETWEEN  TAKEOFFS 

4 

20 

480 

59J 

UNIT  COMBAT  ATTRIT  RATE  FOR  ORDER 

4 

20 

480 

59K 

SORTIES  PER  DAY 

4 

20 

480 

kjt  AmVOi" 


,*•  ,% 


<-*  *jr  -.Vii. 


MAINTENANCE  CONTROL  OR  JOB  CONTROL  (MOC)  (Continued) 


APPSARANCE  TOTAL 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

59H 

PRIHARX  RESOURCE  TYPE 

6 

30 

1080 

73C 

RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

A 

38 

912 

73D 

T  UNIT  MILY  RESOURCE  SORTIE  CAPABIUTY 

A 

2280 

5A720 

73L 

UNIT  RESOURCE  AMOUNT  TASKED 

A 

2280 

5A720 

7AA 

TASKED  UNIT  NAME 

10 

1 

60 

7AB 

RESOURCE  TYPE  IN  UNIT'S  TASKING  PIECE 

20 

38 

A560 

7i|D 

RESOURCE  QUANTITY  REQUIRED  POR  TASK  TYPE 

IN  UNIT'S  PIECE  OP  ORDER 

4 

190 

A560 

TAG 

PLY  DAY  WAVE 

A 

5 

120 

7AJ 

DAILY  TOTAL  SORTIE  RESOURCES  PRODUCED 

A 

10200 

2AA800 

88C 

QUANTITY  OP  TYPE  IK  STATUS 

A 

80 

1920 

92A 

REQUISITION  RESOURCE  TYPE 

20 

20 

2A00 

92B 

DUE-OUT  REQUISITION  NUMBER 

1A 

20 

1680 

92C 

DUB-IN  REQUISITION  NIMBER 

1A 

20 

1680 

92D 

MICAP  START  DATE 

11 

20 

1320 

92E 

HUMBER  OP  MICAP  DAYS 

A 

20 

A80 

92P 

REQUISmOH  CAUSE  CODE 

1 

20 

120 

92G 

REQUISniOH  ROUTE  ID 

3 

20 

360 

92H 

REQUISITION  RBURKS 

30 

20 

3600 

96B 

RESOURCE  NAME 

23 

7 

966 

96C 

RESOURCE  STATUS 

3 

7 

126 

96D 

RESOURCE  ETIC 

11 

7 

A62 

TOTAL  DATA 

SIZE  = 

62195a 

TOTAL  OPERATIONAL  DATABASE 

SIZE  = 

2207936 

32101 


MUNITIONS  CONTROL 


APPEARAHCg 

NUMBER 


APPEARANCE  NAME 


AIRCRAPT  UNIT  NAME 
AIRCRAPT  SERIAL  NUMBER 
AIRCRAPT  MBS 

AIRCRAPT  OPERATIONAL  STATUS 
AIRCRAPT  OPERATIONAL  STATUS  RttlARKS 
AIRCRAPT  LOCATION 
AIRCRAPT  ETIC 

AIRCRAPT  TANK  CONPIOURATION 

AIRCRAPT  STATION  STATUS 

AIRCRAPT  PRESELECT  INDICATOR 

AIRCRAPT  GENERATION  PACTOR 

AIRCRAPT  TAIL  NUMBER 

UNIT  NAME  OWNING  RESOURCE 

RESOURCE  DESIGNATOR 

RESOURCE  AUTHORIZED  AMOUNT 

RESOURCE  SET  IDENTIPIER 

RESOURCE  LAST  IMVENTORlf  DATE 

RESOURCE  ASSIGNED  AMOUNT 

RESOURCE  CURRENT  AMOUNT 

RESOURCE  CURRBin  OPP  BASE  AMOUNT 

BASE  NAME  -  UNIT'S  RESOURCE  LOCATION 

RESOURCE  POSSESSED  TOTAL 

RESOURCE  ROLL-UP  UTG 

RESOURCE  TRANSMIT  DTO 

AIRCREWS  HR 

AIRCRAPT  MC 

H_E11PEKDED  SUPPLt 

REOURCE  CURRENT  BUILT  AMOUNT 

H  OPP  BASE  AMOUNT 

REOURCB  RB1ARKS1 

RBOURCE  SUPPIT  CRITICAL  LEVEL 

RBOURCE  TOTAL  CUHRENILt  AVAIUBLE 

RESOURCE  SUPPLT  DATS  RBMAINIHO 

REOURCE  DAILT  EXPENDITURE  RATE 

REOURCE  SUPPLr  DATS  UNTIL  CRITICAL 

MISSION  NUMBE 

PRIMART  MIEION  TIPE  ASSIGNED 
MISSION  UNIT  NAME 
MIEION  NUMBE  OP  AIRCRAPT 
MISSION  START  TIME  OVER  TARGET 
MISSION  STOP  TIME  OVE  TARGET 
SUPPORT  MISSION  NUMBE 
MISSION  TARGET  DESCRIPTION 
MISSION  PRIORITY 
MIEION  PRIORITY 
MISSION  TURN  BACK  PUG 
MISSION  RBURE 
MISSION  TASKED  MUNITION  CODE 
BASE  NAME 

BASE  OPERATIONAL  STATUS 
BASE  NBC  STATUS 
BASE  ETIC 


32 1 01 


SIZE 

QUANTITY 

SIZE 

to 

4 

240 

« 

80 

1920 

7 

4 

168 

8 

7 

336 

80 

80 

38400 

4 

80 

1920 

5 

80 

2400 

1 

80 

480 

3 

4 

72 

4 

80 

1920 

4 

80 

1920 

5 

80 

2400 

10 

T 

60 

20 

54 

6480 

4 

54 

1296 

23 

I 

138 

7 

54 

2268 

4 

54 

1296 

4 

54 

1296 

4 

54 

1296 

15 

5 

450 

4 

54 

1296 

13 

3 

234 

13 

3 

23A 

4 

2 

48 

4 

2 

48 

4 

30 

720 

4 

30 

720 

4 

30 

720 

30 

30 

5400 

4 

30 

720 

4 

30 

720 

4 

30 

720 

4 

30 

720 

4 

30 

720 

7 

250 

10500 

5 

5 

150 

10 

3 

180 

4 

250 

6000 

5 

250 

7500 

5 

250 

7500 

7 

250 

10500 

15 

250 

22500 

4 

250 

6000 

4 

0 

0 

1 

250 

1500 

60 

250 

90000 

6 

250 

9000 

15 

5 

450 

3 

5 

90 

3 

5 

90 

11 

5 

330 

MUNITIONS  CONTROL  (Continued) 


APPBARAHCg  TOTAL 


NUHBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

530 

BASE  STATUS  RB1ARKS 

140 

5 

4200 

53H 

BASE  STATUS  AS  OP  DTC 

10 

5 

300 

54A 

ORDER  IDENTIPIgR 

23 

1 

138 

54E 

ORDER  DATE 

7 

1 

42 

540 

ORDER  CHANGE  NUMBER 

4 

1 

24 

540 

ORDER  CHANGE  NUMBER 

4 

4 

96 

54K 

ORDER  CU3SIPICATI0N 

21 

1 

126 

56A 

TASKED  UNIT  NAME 

10 

1 

60 

56P 

UNIT  EMPLOYMEIR  DAY 

5 

1 

30 

73C 

RESOURCE  TYPE  SUPPORTIHO  UNIT  TASK 

4 

38 

912 

73P 

T  UNIT  DAILY  RESOURCE  QUANTITY  CAPABLE 

4 

2280 

54720 

73L 

UNIT  RESOURCE  AMOUNT  TASKED 

4 

2280 

54720 

74A 

TASKED  UNIT  NAME 

10 

1 

60 

74B 

RESOURCE  TYPE  IN  UNIT'S  TASKINO  PIECE 

20 

38 

4560 

74D 

RESOURCE  QUANTITY  REQUIRED  POR  TASK  TYPE  IN  UNIT'S  PIECE  OP  ORIXR 

4 

190 

4560 

88C 

QUANTITY  OP  TYPE  IN  STATUS 

4 

80 

1920 

96B 

RESOURCE  NAME 

23 

7 

966 

96C 

RESOURCE  STATUS 

3 

7 

126 

96D 

RESOURCE  ETIC 

11 

7 

462 

96B 

RESOURCE  RBURKS 

4 

0 

0 

TOTAL  DATA  3IZ8  =  380088 

TOTAL  OPBRATIONAL  DATABASE  SIZE  :  1208679 


32101 


B-7 


WING  AND  SQUADRON  SCHEDULING/TRAINING, 
SQUADRON  OPERATIONS,  WING  HQ  (OPS) 


APPBARANCB 

NtMBBH  APPEARANCE  NAME 


1C  UNIT  HI33I0N 

IE  UNIT  OPERATIONS  ICBNTIPIER 

3A  RESOURCE  TYPE  NEEKD  FOR  A  TASK 

8B  TASK  TYPE  SET  lOBNTIPIBR 

8D  RESOURCE  PRIORITY 

SB  STANDARD  QUANTITY  OP  RESOURCE  REQUIRED 

9A  TASK  TYPE 

9B  TASK  PRIORITY 

9C  TASK  TYPE  EXECUTION  TIME 

9E  TASK  PERIOD  PRQH  DAY 

9P  TASK  PBIIOD  TO  DAY 

11A  AIRCRAFT  UNIT  NAME 

1 1B  AIRCRAFT  SERIAL  NUMBER 

1 1C  AIRCRAFT  MDS 

11E  AIRCRAFT  OPERATIONAL  STATUS 

1 1F  AIRCRAFT  OPERATIONAL  STATUS  RBtARKS 

11G  AIRCRAFT  LOCATION 

1 1H  AIRCRAFT  ETIC 

1 1K  AIRCRAFT  TANK  CONFIOURATION 

11L  AIRCRAFT  STATION  STATUS 

11H  AIRCRAFT  PRESELECT  INDICATOR 

11N  AIRCRAFT  GENERATION  FACTOR 

IIP  AIRCRAFT  TAIL  NUHBHt 

12A  AIRMAN  U3T  NAME 

12B  AIRMAN  UNIT  NAME 

12C  AIRMAN  availability  STATUS 

12D  AIRMAN  CREN  DAY  START 

12F  AIRMAN  STATUS  REMARKS 

12G  AIRMAN  RANK 

12H  AIRMAN  ETR 

121  AIRMAN  CRBU  POSITION 

12J  AIRMAN  DUTY  STATUS 

12K  AIRMAN  ATTACHED  UNIT  NAME 

12L  AIRMAN  ASSIGHMEirr  TYPE 

12H  AIRMAN  EXPECTED  MR  DATE 

12N  AIRMAN  DUTY  STATUS  QUAUFIER 

13A  UNIT  NAME  (VNING  RESOURCE 

13B  RESOURCE  DESIGNATOR 

13c  RESOURCE  AUTHORIZED  AMOUNT 

I3D  RESOURCE  SET  IDBirriFIER 

I3E  RESOURCE  LAST  IHVENTORT  DATE 

13G  RESOURCE  ASSIGNED  AMOUNT 

I3H  RESOURCE  CURRENT  AMOUNT 

131  RESOURCE  CURRENT  OFF  BASE  AMOUNT 

13J  BASE  NAME  -  UNIT'S  RESOURCE  LOCATION 

13H  RESOURCE  POSSESSED  TOTAL 

13P  AIRCREWS  NR 

I3R  H  EXPENDED  SUPPLY 

1 3S  R^URCE  CURRENT  BUILT  AMOUNT 

13T  H  OFF  BASE  AMOUNT 

13U  R^URCE  REMARKS  1 

13V  RESOURCE  SUPPLY  CRITICAL  LEVEL 


SIZE  QUANTITY 


3 

5 

23 

1 

23 

n 

23 

1 

4 

35 

4 

1100 

18 

100 

4 

100 

4 

1 

4 

20 

4 

20 

10 

4 

4 

80 

7 

4 

8 

7 

80 

80 

4 

80 

5 

80 

1 

80 

3 

4 

4 

80 

4 

80 

5 

80 

16 

216 

8 

3 

1 

216 

5 

216 

80 

216 

5 

216 

11 

216 

3 

5 

5 

10 

10 

3 

2 

216 

5 

216 

2 

216 

10 

1 

20 

54 

4 

54 

23 

1 

7 

54 

4 

54 

4 

54 

4 

54 

15 

5 

4 

54 

4 

2 

4 

30 

4 

30 

4 

30 

30 

30 

4 

30 

TOTAL 

SIZE 


90 

138 

1518 

138 

8A0 

26a  00 
10800 
2A00 
2A 
A80 
480 
240 

1920 

168 

336 

38400 

1920 

2100 

480 

72 

1920 

1920 

2400 

20736 

144 

6480 

103680 

6480 

14256 

90 

300 

180 

2592 

6480 

2592 

60 

6480 

1296 

138 

2268 

1296 

1296 

1296 

450 

1296 

48 

720 

720 

720 

5400 

720 


I 

I 

I 

» 


WING  AND  SQUADRON  SCHEDULING/TRAINING, 
SQUADRON  OPERATIONS,  WING  HQ  (OPS)  (Continued) 


APPEARANCE 

Nwun 

APPEARANCE  NAME 

SIZE 

QUAIfTITY 

TOTAL 

SIZE 

13N 

RESOORCE  TOTAl  CORRENTIV  AVAIIABLE 

4 

30 

720 

13X 

RESOURCE  SUPPIV  DAYS  RBUININO 

4 

30 

720 

13* 

RESOORCE  DAIIY  EXPENOITURE  RATE 

4 

30 

720 

13Z 

RESOURCE  SUPPIY  OAYS  UNTll  CRITICAl 

4 

30 

720 

15C 

MISSION  NWBER 

7 

250 

10500 

15D 

PRIMARY  MISSION  TYPE  ASSIGNED 

5 

5 

150 

15E- 

MISSION  UNIT  NAME 

10 

3 

180 

15P 

MISSION  NUHB0  OP  AIRCRAFT 

4 

250 

6000 

150 

MISSION  START  TIME  OVER  TARGET 

5 

250 

7500 

15H 

MISSION  STOP  TIME  OVER  TARGET 

5 

250 

7500 

151 

SUPPORT  MISSION  NUMBER 

7 

250 

10500 

15H 

MISSION  TAROR  DESCRIPTION 

15 

250 

22500 

150 

MISSION  PRIORITY 

4 

250 

6000 

150 

MISSION  PRIORITY 

4 

0 

0 

15U 

MISSION  TURN  BACK  PUG 

1 

250 

1500 

15V 

MISSION  RBURXS 

60 

250 

90000 

15W 

MISSION  TASKED  MUMITION  CODE 

6 

250 

9000 

20H 

RESOORCE  SUPPLY  lOBmiPIBR 

23 

1 

138 

50A 

SORTIE  SEQUENCE  NUMBER 

4 

375 

9000 

500 

SORTtE  AS3I0NE0  TAKB-OPP  TIHE 

5 

375 

11250 

50E 

SORTIE  EXPECTED  lAND  TIME 

5 

375 

11250 

50P 

SORTIE  AIRCRBN  SHOW  TIME 

5 

375 

11250 

500 

SORTIE  AIRCREW  COMPLETION  TIME 

5 

375 

11250 

503 

SORTIE  MISSION  AIRCRAFT  M08 

7 

4 

168 

53A 

BASE  NAME 

15 

5 

450 

530 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53B 

BASE  NBC  STATUS 

3 

5 

90 

53P 

BASE  STIC 

11 

5 

330 

530 

BASE  STATUS  RBURKS 

140 

5 

4200 

53H 

BASE  STATUS  AS  OP  OTO 

10 

5 

300 

5AA 

ORDER  IDEirriP3R 

23 

1 

138 

5AA 

ORDBI  lOENTIPin 

23 

4 

552 

5AE 

ORDER  DATE 

7 

1 

42 

5A0 

ORDER  CHANGE  NUMBER 

4 

1 

24 

54K 

ORIBR  CUSSIPICATION 

21 

1 

126 

540 

NUNBBt  CP  DAYS  TO  RUN  SQM  MODEL 

4 

10 

240 

54R 

SORTIE  GENERATION  MODEL  RUN  REMARKS 

45 

10 

2700 

56A 

TASKED  UNIT  NAME 

10 

1 

60 

560 

UNIT  ORDER  IDEKIPICATION 

23 

1 

138 

56E 

BASE  NAME  -  UNIT  WPLOYMENT  LOCATION 

15 

90 

56P 

UNIT  OfPLOYMEIR  DAI 

5 

1 

30 

560 

T  UNIT  DAILY  SORTIE  TASK 

4 

60 

1440 

56J 

UNIT  PUNNED  SORTIE  DURATION 

4 

60 

1440 

56K 

UNIT  SHIFT  DURATION 

4 

60 

1440 

561 

UNIT  PLY  DAY  NUMBER 

4 

60 

1440 

56N 

T  UNIT  DAILY  RESOURCE  QUANTITY  TASKED 

4 

60 

1440 

59B 

UNIT  NAME 

7 

1 

42 

59C 

UNIT  TURN  TIME  FOR  ORDER 

4 

20 

480 

590 

PERIOD  START  DAI  FOR  UNIT'S  PIECE  OP  ORDER 

4 

20 

480 

59E 

POtlOD  END  DAY  FOR  UNIT'S  PIECE  OP  ORDER 

4 

20 

480 

59P 

UNIT  MAINT  ATTRIT  RATE  FOR  ORDER 

4 

20 

480 

590 

MISSION  TYPE 

5 

5 

150 

SOFfeo 


32101 


B-9 


V  V  V  >•  iT 


WING  AND  SQUADRON  SCHEDULING/TRAINING, 
SQUADRON  OPERATIONS,  WING  HQ  (OPS)  (Continued) 


APPBARAHCE  TOTAL 


NUMBER 

APPEARANOB  NAME 

SIZE 

QUANTITY 

SIZE 

59H 

UNIT  AIRORAPT  REPAIR  RATE  POR  ORUER 

A 

20 

480 

591 

UNIT  MIN  TIME  BETWEEN  TAKEOPPS 

4 

20 

480 

59J 

UNIT  OCMBAT  ATTRIT  RATE  POR  ORBBR 

4 

20 

480 

59K 

SORTIES  PBI  DAY 

4 

20 

480 

59L 

MISSION  PRIORITY 

4 

5 

120 

59M 

PRIMARY  RESOUROE  TYPE 

6 

30 

1080 

6U 

AIRMAN  UST  NAME  -  POSSESSOR  OP  SKILL 

16 

216 

20736 

61B 

SKILL  IDBIRIPIER  -  3KIU  POSSESSED 

3 

20 

360 

610 

SKILL  LEVEL 

1 

10 

60 

61D 

SKILL  IDBHTIPIER  -  RESOUROE 

13 

20 

1560 

71A 

ORDER  IDENIIPIER 

23 

1 

138 

7  IB 

TASK  PBIIOD  START  DAY 

4 

20 

480 

710 

TASK  PERIOD  END  DAY 

4 

20 

480 

71D 

RESOUROE  TYPE  REQUIRED  POR  TOTAL  ORKR 

20 

38 

4560 

71E 

RESOURCE  QUANTITY  REQUIRED  POR  TOTAL  ORDER 

4 

2280 

54720 

71P 

SORTIE  AIRORAPT  RATS 

4 

180 

4320 

7  IQ 

SORTIE  DURATION 

4 

300 

7200 

73A 

UNIT  NAME  -  POR  TASKED  UNIT 

10 

1 

60 

730 

RESOURCE  TYPE  SUPPORTINO  UNIT  TASK 

4 

38 

912 

73D 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY 

4 

2280 

54720 

73? 

T  UNIT  DAILY  RESOURCE  QUANTITY  CAPABLE 

4 

2280 

54720 

73L 

UNIT  RESOURCE  AMOUNT  TASKED 

4 

2280 

54720 

7AA 

TASKED  UNIT  NAME 

10 

1 

60 

7AB 

RESOURCE  TYPE  IN  UNIT'S  TASKINQ  PIECE 

20 

38 

4560 

7AD 

RESOURCE  QUANTITY  REQUIRED  POR  TASK  TYPE  IN  UNIT'S  PIECE  ON  ORDER 

4 

190 

4560 

7A0 

PLY  DAI  WAVE 

4 

5 

120 

7AJ 

DAILY  TOTAL  SORTIE  RESOURCES  PRODUCED 

4 

10200 

244800 

880 

QUANTITT  OP  TYPE  IN  STATUS 

4 

80 

1920 

88D 

RESOURCE  TYPE  OP  UNIT'S  SUPPLY  IN  STATUS 

20 

54 

6480 

89N 

PLY  DAY  START 

5 

20 

600 

890 

SHIFT  PERCENT  FORMED  AIRCREW 

4 

40 

960 

89P 

PLY  DAY  DURATION 

2 

20 

240 

890 

SHIFT  START  TIME 

5 

40 

1200 

96B 

RESOURCE  NAME 

23 

7 

966 

960 

RESOURCE  STATUS 

3 

7 

126 

96D 

RESOURCE  ETIC 

11 

7 

462 

96B 

RESOURCE  RBtARKS 

4 

0 

0 

TOTAL  DATA 

SIZE  = 

1062342 

TOTAL  OPERATIONAL  DATABASE  SIZE  = 

2464633 

0 

\  • 


SUPPLY 


APPBARANCB  TOTAL 


NUHBBR 

*PPB*R*NC8  N*HB 

SIZE 

QUANTITY 

SIZE 

IP 

UNIT  SHORT  HAMS 

8 

4 

192 

5A 

RBsouRCB  rm 

20 

42 

5040 

5B 

RB30URCB  UNITS  OP  HBASURB 

8 

5 

240 

IIA 

AIRCRAPT  UNIT  NAH8 

10 

4 

240 

11B 

AIRORAPT  SBRIAL  NUMBER 

A 

80 

1920 

nc 

AIRORAPT  MBS 

7 

4 

168 

118 

AIRORAPT  OPBRATIONAL  STATUS 

8 

7 

336 

IIP 

AIRCRAPT  OPBRATIONAL  STATUS  RB1ARXS 

80 

80 

38400 

11G 

AIRCRAPT  LOCATION 

4 

80 

1920 

11H 

AIRCRAPT  BTIC 

5 

80 

2400 

11K 

AIRCRAPT  TANK  CONPIOURATION 

1 

80 

480 

111 

AIRCRAPT  STATION  STATUS 

3 

4 

72 

11« 

AIRCRAPT  PRBSBLBCT  INDICATOR 

4 

80 

1920 

11N 

AIRCRAPT  OBNBRATION  PACTOR 

4 

80 

1920 

IIP 

AIRCRAPT  TAIL  NUKBBR 

5 

80 

2400 

13* 

UNIT  NAHB  OWNINO  RBSOURCB 

10 

1 

60 

13B 

RBSOURCB  DBSIONATQR 

20 

54 

6480 

13c 

RBSOURCB  AOTHORIZBD  AMOUNT 

4 

54 

1296 

130 

RBSOURCB  ASSIONBO  AMOUNT 

4 

54 

1296 

13M 

RBSOURCB  CURRBNT  AMOUNT 

4 

54 

1296 

131 

RBSOURCB  CURRBNT  OPP  BASB  AMOUm 

4 

54 

1296 

13M 

RBSOURCB  POSSBSSED  TOTAL 

4 

54 

1296 

20A 

UNIT  NAMB  OP  SUPPLY  OWNBR  AT  THIS  LOCATION 

10 

1 

60 

ZOB 

RBSOURCB  TTPB  OP  SUPPLY  AT  THIS  LOCATION 

20 

54 

6480 

20C 

SUPPLY  LOCATION  TYPB 

15 

2 

180 

SUPPLY  LOCATION  NIMBER 

12 

92 

6624 

208 

SUPPLY  LOCATION  RBSOURCB  CAPACITY 

4 

12 

288 

20P 

T  SUPPLY  LOCATION  RBSOURCB  INVBIRORY 

4 

12 

288 

200 

SUPPLY  LOCATION  RBSOURCB  INVENTORY  OATB 

7 

12 

504 

20J 

STORAOB  CONTAINBR  SBRVICBABIUTY 

15 

12 

1080 

20K 

STORAOB  CONTAINHI  BTIC 

12 

12 

864 

20L 

STORAOB  CONTAINBR  RB1ARIQ 

15 

12 

1080 

39A 

OWNINO  RBSOURCB  DBSIONATOR 

20 

25 

3000 

39B 

SUBOROINATB  RBSOURCB  DBSIONATOR 

20 

54 

6480 

53* 

BASB  NAMB 

15 

5 

450 

BASB  OPBRATIONAL  STATUS 

3 

5 

90 

538 

BASB  NBC  STATUS 

3 

5 

90 

53P 

BASE  BTIC 

11 

5 

330 

BASE  STATUS  RBtARKS 

140 

5 

4200 

53H 

BASB  STATUS  AS  OP  DTO 

10 

5 

300 

880 

QUANTITT  OP  TTPB  IN  STATUS 

4 

80 

1920 

92* 

REQUISITION  RESOURCE  TYPB 

20 

20 

2400 

92B 

DUB-OUT  REQUISITION  NUMBER 

14 

20 

1680 

920 

DUE-IN  REQUISITION  NUHBBR 

14 

20 

1680 

92D 

MICAP  START  DATS 

11 

20 

1320 

92B 

NUHBBR  OP  MICAP  DAIS 

4 

20 

480 

92P 

RBQUISITION  CAUSE  CODB 

1 

20 

120 

920 

REQUISITION  ROUTS  ID 

3 

20 

360 

92H 

RBQUISITION  RBIARIC3 

30 

20 

3600 

92J 

RBQUISITION  UNIT  NAMB 

10 

20 

1200 

96B 

RBSOURCB  NAMB 

23 

7 

966 

960 

RBSOURCB  STATUS 

3 

7 

126 

SUPPLY  (Continued) 


I 


AFPEARANCB 

NUHBBl  APFBARANCB  NAME 


96D  RESOURCE  snC 

96e  resource  RBURKS 


TOTAL 


SIZE  QUANTITY 

SIZE 

11  7 

462 

4  0 

0 

TOTAL  DATA  SIZE  i 

119370 

TOTAL  OPERATIONAL  DATABASE  SIZE  = 

225609 

WING  OPERATIONS  CENTER 

(CSS,  LRC,  PRC,  SRC,  SR.  BATTLESTAFF,  MISSION  DIRECTOR,  FRAG  SHOP)  (WOC) 


APPBARANCB  TOTAL 


NUMBER 

APPBARANCB  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

5 

90 

IE 

UNIT  OPBRATIONS  lUBirriPIER 

23 

1 

138 

UNIT  SHORT  NAMB 

k. 

A 

192 

5A 

RESOURCE  TYPE 

20 

A2 

5OA0 

5E 

RESOURCE  UNITS  OP  MEASURE 

8 

5 

2A0 

8A 

RESOURCE  TYPE  NEEDED  POR  A  TASK 

23 

11 

1518 

8B 

TASK  TYPE  SET  IDBNTIPIER 

23 

1 

138 

8D 

RESOURCE  PRIORITY 

A 

35 

8A0 

8E 

STANDARD  QUANTITY  OP  RESOURCE  REQUIRED 

A 

1100 

26A00 

9A 

TASK  TYPE 

18 

100 

10800 

9B 

TASK  PRIORITY 

A 

100 

2A00 

9C 

TASK  TYPE  BXECiniON  TIME 

A 

1 

2A 

9E 

TASK  PR  100  PRCH  DAY 

A 

20 

ABO 

9R 

TASK  PERIOD  TO  DAY 

A 

20 

ABO 

11A 

AIRCRAPT  (MR  NAMB 

10 

A 

2A0 

11B 

AIRCRAPT  SERIAL  NUHBBl 

A 

80 

1920 

lie 

AIRCRAPT  NDB 

7 

A 

168 

11E 

AIRCRAPT  OPERATIONAL  STATUS 

8 

7 

336 

IIP 

AIRCRAPT  OPERATIONAL  STATUS  RBtARKS 

BO 

80 

3BAOO 

110 

AIRCRAPT  LOCATION 

A 

80 

1920 

11H 

AIRCRAPT  STIC 

5 

80 

2A00 

11K 

AIRCRAPT  TANK  CONPIOURATION 

1 

80 

A80 

11L 

AIRCRAPT  STATION  STATUS 

3 

A 

72 

11M 

AIRCRAPT  PRESELECT  INDICATOR 

A 

80 

1920 

11M 

AIRCRAPT  OBNERATION  PACTOR 

A 

80 

1920 

IIP 

AIRCRAPT  TAU  NUMBER 

5 

BO 

2A00 

I2A 

AIRMAN  LAST  NAMB 

16 

216 

20736 

12B 

AIRMAN  UNIT  NAME 

8 

3 

lAA 

12C 

AIRMAN  AVAILABILITY  STATUS 

1 

216 

1296 

12D 

AIRMAN  CRW  DAY  START 

5 

216 

6ABO 

12P 

AIRMAN  STATUS  RBtARKS 

80 

216 

103680 

120 

AIRMAN  RANK 

5 

216 

6ABO 

12H 

AinUN  ETR 

11 

216 

1A256 

121 

AIRMAN  CREW  POSITION 

3 

5 

90 

12J 

AinUN  DOTY  STATUS 

5 

10 

300 

12K 

AIRMAN  ATTACHED  UNIT  NAMB 

10 

3 

180 

12L 

AIRMAN  ASSIONIENT  TYPE 

2 

5 

60 

12n 

AIRMAN  EXPECTED  HR  DATE 

5 

216 

6A80 

12N 

AIRMAN  DOTY  STATUS  QUALIPIBI 

2 

10 

120 

13A 

UNIT  NAME  (MNINO  RESOURCE 

10 

1 

60 

13B 

RESOURCE  DB3I0NAT0R 

20 

5A 

6A80 

13C 

RESOURCE  AOTHORIZED  AMOUNT 

A 

5A 

1296 

13D 

RESOURCE  SET  IDBOTIPIER 

23 

1 

138 

13E 

RESOURCE  LAST  INVENTORY  DATE 

7 

5A 

2268 

130 

RESOURCE  ASSIONBD  AMOUNT 

A 

5A 

1296 

13H 

RESOURCE  CURRENT  AMOUNT 

A 

5A 

1296 

131 

RESOURCE  CURRENT  OPP  BASE  ANOUNT 

A 

5A 

1296 

iy 

BASE  NAME  -  UNIT'S  RESOURCE  LOCATION 

15 

5 

A50 

13W 

RESOURCE  POSSESSED  TOTAL 

A 

5A 

1296 

13» 

RESOURCE  ROll-UP  DTG 

13 

3 

23A 

130 

RESOURCE  TRANSMIT  DTO 

13 

3 

23A 

13P 

AIRCREWS  HR 

A 

2 

A8 

32101 
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WING  OPERATIONS  CENTER 

(CSS,  LRC,  PRC,  SRC,  SR.  BATTLESTAFF,  MISSION  DIRECTOR,  FRAG  SHOP) 

(woe)  (Continued) 


APPBARANC8 


TOTAL 


6 


r 

s." 

! 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

130 

AIRCRAPT  HC 

4 

2 

48 

13R 

H  EXPENOBD  SUPPLY 

4 

30 

720 

133 

RESOURCE  CURRENT  BUILT  AMOUNT 

4 

30 

720 

13T 

H  OPP  BASE  AMOUNT 

4 

30 

720 

13U 

RESOURCE  RB1ARKS1 

30 

30 

5400 

13V 

RESOURCE  SUPPLY  CRITICAL  LEVEL 

4 

30 

720 

13W 

RESOURCE  TOTAL  CURRENTLY  AVAIUBLE 

4 

30 

720 

13X 

RESOURCE  SUPPLY  BAYS  REMAINING 

4 

30 

720 

131 

RESOURCE  OAILY  EXPENOITURE  RATE 

4 

30 

720 

13Z 

RESOURCE  SUPPLY  BAYS  UNTIL  CRITICAL 

4 

30 

720 

15C 

MISSION  NUMBER 

7 

250 

10500 

15D 

PRIMARY  MISSION  TYPE  ASSIGNEO 

5 

5 

150 

19! 

MISSION  UNIT  NAME 

10 

3 

180 

15P 

MISSION  NUMBER  OP  AIRCRAPT 

4 

250 

6000 

150 

MISSION  START  TIME  OVER  TAROET 

5 

250 

7500 

’5H 

MISSION  STOP  TIME  OVER  TAROET 

5 

250 

7500 

15L 

SUPPORT  MISSION  NUMBER 

7 

250 

10500 

15M 

MISSION  TARGET  OBSCRIPTION 

15 

250 

22500 

150 

MISSION  PRIORITY 

4 

250 

6000 

150 

MISSION  PRIORITY 

4 

0 

0 

150 

MISSION  PRIORITY 

4 

0 

0 

15U 

MISSION  TURN  BACK  PUO 

1 

250 

1500 

15V 

MISSION  RB1ARKS 

60 

250 

90000 

15W 

MISSION  TASKED  MUNITION  CODE 

6 

250 

9000 

20A 

UNIT  NAME  OP  SUPPLY  OWNER  AT  THIS  LOCATION 

10 

1 

60 

20B 

REKjmWE  TYPE  OP  SUPflt  AT  THIS  LOCATION 

20 

54 

6480 

20C 

SUPPLY  LOCATION  TYPE 

15 

2 

180 

200 

SUPPLY  LOCATION  NUMBER 

12 

92 

6624 

20B 

SUPPLY  LOCATION  RESOURCE  CAPACITY 

4 

12 

288 

20P 

T  SUPPLY  LOCATION  RESOURCE  INVERTORY 

4 

12 

288 

20Q 

SUPPLY  LOCATION  RESOURCE  INVENTORY  DATE 

7 

12 

504 

20H 

RESOURCE  SUPPLY  lOBNYIPIER 

23 

1 

138 

20J 

STORAGE  CONTAINBR  3ERVICBABIUTY 

15 

12 

1080 

2  OK 

STORAGE  CONTAINER  ETIC 

12 

12 

864 

20L 

STORAGE  CONTAINER  REMARKS 

15 

12 

1080 

39A 

OWNING  RESOURCE  DESIGNATOR 

20 

25 

3000 

39B 

SUBOROINATB  RESOURCE  DESIGNATOR 

20 

54 

6480 

50A 

SORTIE  SEQUENCE  NUMBS) 

4 

375 

9000 

500 

SORTIE  ASSIGNED  TAKE-OPP  TIME 

5 

375 

11250 

50E 

SORTIE  EXPECTED  UND  TIME 

5 

375 

11250 

SOP 

SORTIE  AIRCREW  SHOW  TIHB 

5 

375 

11250 

500 

SORTIE  AIRCREW  COMPLETION  TIME 

5 

375 

11250 

503 

SORTIE  MISSION  AIRCRAPT  MBS 

7 

4 

168 

53* 

BASE  NAME 

15 

5 

450 

530 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53E 

BASS  NBC  STATUS 

3 

5 

90 

53P 

BASE  ETIC 

11 

5 

330 

530 

BASE  STATUS  RBURKS 

140 

5 

4200 

53H 

BASE  STATUS  AS  OP  DIO 

10 

5 

300 

54A 

OROB)  IDBIRIPIER 

23 

1 

138 

548 

ORIER  DATE 

7 

1 

42 

540 

ORDER  CHANGE  NUMBER 

4 

1 

24 

32101 
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WING  OPERATIONS  CENTER 

(CSS,  LRC,  PRC,  SRC,  SR.  BATTLESTAFF,  MISSION  DIRECTOR,  FRAG  SHOP) 

(woe)  (Continued) 


UPPBAMNCS 

MUHBBt 


APPBARANCB  NANS 


SIZE  QUAHTITY 


ORKR  CUSSiriCATION 

NUHBBt  OP  DAIS  TO  RUN  SOH  HOKL 

SORTB  CCNBRATION  HOKL  RUN  RB1ARXS 

TASKBB  UNIT  NAMB 

UNIT  ORIBR  UCNTIPICATION 

BASB  NAtS  -  UNIT  mPLOYMEm  LOCATION 

UNIT  EMPLOYMENT  DAY 

T  UNIT  DAILY  SORTIE  TASK 

T  UNIT  DAILY  INTEGRATED  SORTIE  CAPABILITY 

UNIT  PUNNED  SORTIE  DURATION 

UNIT  SKINT  DURATION 

UNIT  PLY  DAT  NUMBER 

T  UNIT  DAILY  RESOURCE  QUAmiTY  TASKED 

UNIT  NAMB 

UNIT  TORN  TIME  POR  ORDER 
PERIOD  START  DAI  POR  UNIT'S  PIECE  OP  ORDER 
PERIOD  BHD  DAT  POR  UNIT'S  PIECE  OP  ORDER 
UNIT  HAINT  ATTRIT  RATE  POR  ORDER 
MISSION  TYPE 

UNIT  AIRCRAPT  REPAIR  RATE  POR  ORDER 

UNIT  MIN  TIME  BETWEEN  TAKBOPPS 

UNIT  COMBAT  ATTRIT  RATE  POR  ORDER 

SORTIES  PER  DAY 

MISSION  PRIORITY 

PRIHART  RESOURCE  TYPE 

AimAN  U3T  NAMB  •  POSSESSOR  OP  SKILL 

SKILL  IDBNTIPIBR  -  SKILL  POSSESSED 

sKiu  um 

SKILL  IDENIIPIBR  -  RESOURCE 

ORDER  IDENtlPIER 

TASK  PERIOD  START  DAY 

TASK  PERIOD  END  DAY 

RESOURCE  TYPE  REQUIRED  POR  TOTAL  ORDER 

RESOURCE  QUANTITY  REQUIRED  PCR  TOTAL  ORDER 

SORTIE  AIRCRAPT  RATE 

SORTIE  DURAHON 

UNIT  NAME  -  POR  TASKED  UNIT 

RESOURCE  TYPE  SUPPORTINO  UNIT  TASK 

T_UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY 

TJINIT  DAILY  RESOURCE  QUANTITY  CAPABLE 

UNIT  RESOURCE  AMOUNT  TASKED 

TASKED  UNIT  NAME 

RESOURCE  TYPE  IN  UNIT'S  TASKING  PIECE 

RESOURCE  QUANTITY  REQUIRED  POR  TASK  TYPE  IN  UNIT'S  PIECE  OP  ORDER 
PLY  DAY  WAVE 

DAILY  TOTAL  SORTIE  RESOURCES  PRODUCED 
QUANTITI  OP  TYPE  IN  STATUS 
RESOURCE  TYPE  OP  UNIT'S  SUPPLY  IN  STATUS 
PLY  DAY  START 

SHIPT  PERCENT  FORMED  AIRCREW 
PLY  DAY  DURATION 
SHIPT  START  TIME 
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